Agile development, especially scrum, often includes a work estimate of the project (and/or the sprint). Work estimates can also be skipped (see #NoEstimates) in agile projects. In fact, I always recommend asking yourself: do we really need work estimates? At the end of the day, estimates take time from the developers, which is time off from actual development tasks.
If you choose to do estimates in an agile project, the standard practice is using planning poker. The main idea is that rather than estimating tasks in hours, you estimate the relative effort required to complete different tasks of the backlog. Typically story points are used, which are unitless numbers. You pick a simple task and assign 1 to it, then estimate others against it. A task of 2 story points should take roughly twice the effort compared to the simple task.
Planning poker cards are used to estimate tasks in scrum
The whole team must reach a consensus for the estimate of each task. After the session your backlog has estimates, which can e.g. support the selection of tasks to the next sprint.
Since the estimates use story points, the estimated backlog doesn’t directly give a time estimate for the whole project (which is what stakeholders often would prefer to know). In agile development such an estimate is based on empirical data. After one or more sprints velocity can be calculated, which means the average number of story points the team can complete in a sprint.
Once the velocity is known (to some accuracy), one can make a forecast of time required to complete the project. If the team can complete 10 story points in a sprint and the backlog contains 100 story points, the project should be completed in 10 sprints. In reality (and in agile process), requirements however change. New features can be added to the backlog and others removed. Therefore the forecast should be considered rough, especially since the story point estimates themselves tend to be quite inaccurate. The forecast is often visualized with a burndown chart.
Burndown chart visualized the remaining work
There are, however, more challenges with the burndown chart. Once the application grows in complexity, the effort required to implement each story might grow, especially if technical debt increases over time. On the other hand, the team can become more experienced with the tech stack and the domain, and the code base can support further features better. These factors essentially makes any estimate less reliable.
An additional problem some applications face is that the tasks to be implemented are not picked randomly from the backlog. One can imagine that there are different types of features, say A, B and C. The team might first implement mostly A and B features, which will define the team’s velocity. However, perhaps the C features take multiple times more effort, which can invalidate the forecast made in the beginning.
Traditional project management is based on budgets, estimates and schedules. Agile development offers more accurate estimates than traditional methods, but stakeholders should still understand that estimates are usually rather inaccurate. They will, however, become more accurate as the project progresses.
If you’d like our planning poker deck, or need help facilitating a planning poker session, feel free to contact us.
Comments