Lecture Notes, CS3281 AY 1415, Lecture 4

nus-cs3281-2014-l4.md

On Software Project Estimation and Planning

CS3281/CS3282 Lecture Notes

Semester 1, AY 2014/15

2 September 2014

• By end of this week, you should roughly know what to implement and how to implement. It is time to start implementing.
• Principles:
  • Divide into 7-8¹ iterations (Week 5 to Week 11)
  • Goal: One usable prototype every week.
  • Timeboxing: Whatever features that are implemented by Week 11 will be included in the final deliverable.
  • Make sure the important features are implemented first.
  • Estimate the time/effort needed to complete a task, as a team.
  • Algorithm: pack the most important tasks that fit into the current iteration; repeat until full.
  • Each task, therefore, must fit into an iteration (two work sessions).
  • Setup tools (Kanban) to visualize the state of the project

Task Prioritization

• In Agile development lingo, the tasks are called work items and the product backlog is a sorted list of work items, in decreasing order of priority.
• Work as a team (or as project manager) to priotize the work items.
• Note: the priority may change over time. Items may be added/deleted.

Software Estimation Techniques

• ``Despite decades of research, there is no consensus on which software effort estimation methods produce the most accurate models. " -- Ekrem Kocaguneli, Tim Menzies, and Jacky Keung. "On the value of ensemble effort estimation", TSE 2011.

• The effort-accuracy curve of software estimation (Cohn, Figure 6.1)

• Use Case Points

• Story Points

  • Estimate complexity, not time needed to implement a story (or feature, or use case, or component)
  • Story point/Time is the velocity. Estimate velocity based on how many story points you get to finish in the past iterations.
  • A task with 2 points takes twice as long to complete than a task with 1 point.
  • Benchmark yourself with a task that is a 2 and another task that is a 5.
  • Estimate the rest.

• Ideal Time

  • How long would it take for you to implement the story, if (i) there is no interruption, (ii) you know what needs to be done, and (iii) you have everything you need.
  • Elapsed Time = (1 + overhead)*Ideal Time

• Everyone on the team should ``own'' the estimation (not decided by the leader).

• Planning Poker® approach:

  • Get consensus from everyone on the estimation.
  • For each story, everyone announces their estimate.
  • If no consensus, the one with the highest and lowest estimate explain their estimate. (You will likely identify the ambiguity in the scope of the requirements/design here!)
  • Repeat until there is a consensus.
  • Don't: let someone solely be responsible for deciding the estimate
  • Don't: average everyone's estimate.

Using Kanban (看板)-like Techniques for Task Tracking

• Visualize the state of the project by dividing the work items into four columns: Backlog, Ready, Doing, Done.
• When an item is moved from Doing to Done, another item moves from Ready to Doing, and some items may move from Backlog to Ready.
• Put items that are most important into Ready (dynamic prioritization, so no need to strictly sort the Backlog!)
• At a glance: Are bandwidth fully utilize? More things to do than the bandwidth (too many items under Doing)? Throughput?
• Combining Kanban with Iteration Planning: put tasks in the current iteration into Backlog.
• Free online Kanban tools available (Trello is popular among previous teams).
• Flexible and can adapt to your work flow (e.g., Split Doing into Developing, Reviewing, Merging)

Relevant Readings:

• Chapter on "Techniques for Estimating" in the Book "Agile Estimating and Planning" by Mike Cohn. The book is summarized here.

• What We Do and Don't Know about Software Development Effort Estimation

• Scramban by Corey Ladas.

Footnotes

1. Depending on whether you want to break during recess week or not. ↩