Scrum, tasks & task estimates

At the start of an iteration our Scrum team determines the tasks involved to realize each story and estimates them. This is an activity which can take a lot of time and, if your not careful, a lot of energy. When that happens, be prepared for whispers or even loud complaints about "micro management". In this post I explain why we need tasks and estimates.

In Scrum, the user stories to be realized in the next iteration have already been estimated at a high level. Teams often estimate them in so-called story points, which indicate a relative effort required to deliver that story: the higher the number (of story points), the more effort required. At my current employer, we use the values 1 (extra small), 2, 4, 8, 16 and 32 (extra large).

The team assigns story points by comparing the new stories to older, realized ones and the story points assigned to them. When the number of story points that the team has realized in previous iterations is (relatively) stable, we use it to predict the velocity of the team in the next iteration. The stories that are selected for that iteration should fit the velocity of the team.

As mentioned, these story points are a high-level estimate and, unless you are a really experienced and gelled team, the stories contain too much unknowns to plan and monitor the current iteration. This is were tasks and estimates come in. They should provide us with

1. a better understanding of the work that needs to be done,
2. a shared understanding of the work that needs to be done, and
3. a burndown chart to track our progress [1].

The better understanding should lead to better estimates that tell us whether the iteration is overloaded or underloaded. We use these estimates to track progress throughout the sprint so we can

• keep stakeholders informed during the sprint,
• re-allocate people and resources when necessary,
• add, remove or modify stories.

It can be tempting to define the perfect breakdown and find the perfect estimates, whatever those may be. If that works for your team, good for you but avoid drowning in a kind of mini-waterfall. For me the big a-ha moment was that we track progress on stories and not on tasks. The task breakdown should provide you with a better understanding of the work that has to be done and hopefully better estimates. That is their purpose. Keep in mind that the best understanding often comes from doing the actual work.

So what if the actual work deviates from the breakdown? In that case you should adapt the amount of work remaining according to your new insights. In this way the burndown reflects that slow-down or speed-up.