A Cure for Task Estimation Obsession

I often see scrum teams obsess over sprint planning, especially the task of estimating. I mean really obsess. Two days of planning for a two-week sprint? Believe it or not, it happens. Even as they complain about spending too much time in scrum meetings, they will insist on arm-wrestling over each and every task estimate. For teams that want to take advantage of their scrum experience and streamline their planning, eliminating task estimates might just be the right option.

Don’t look so shocked. It is possible. One big caveat, though. For those teams that are new to scrum, I do not recommend eliminating task estimates until you have established a stable velocity.

Once you have a stable velocity, you can use the concepts of story points and velocity to eliminate the need for task estimates in sprint planning. The time you spent estimating tasks can then be used more wisely to create working software. I will present a series of steps you can take to gradually eliminate task estimation from your sprint planning process.

Let’s quickly recall the reasons why we do the sprint planning things that we do. 

We plan the sprint to create the following:

1. A shared understanding across the team of the goals of the sprint;

2. A shared understanding of the work that needs to be done during the sprint;

3. An environment in which team members know what to do next (or can find out in seconds);

4. An achievable team commitment to deliver a certain amount of value, expressed as product backlog items; and,

5. A burndown chart that we can use to track our progress through the sprint.

Task estimates most often contribute to goal five above, and for some teams, to goal four. If we can achieve those two items without creating task estimates, then we are free to choose not to use task estimates at all, aren’t we? If you agree, here’s a way to transition away from doing task estimates as part of your sprint planning.

Step 1. Establish Stable Velocity

Use your normal sprint planning process, whether it takes two days or two hours, for each sprint until you can demonstrate stable velocity. (There are many discussions of how to achieve stable velocity out there; it is too large a subject to discuss here. For more on agile estimation, I recommend Mike Cohn’s Agile Estimating and Planning.) Make sure your team passes the Nokia test by producing potentially shippable software each sprint (in other words, you’ve proven that you can calculate your velocity correctly). When you have achieved stable velocity, your team will be able to make, and meet, sprint commitments based solely on demonstrated velocity and story point estimates of product backlog items. You want to do this anyway as part of having a good scrum implementation, right? 

Related Article: What is Scrum Team Velocity 

Step 2: Experiment with a Task-Based Burndown

When you think you’re ready to stop estimating tasks, start to use two burndown charts instead of one. Continue to use your normal work-based burndown, which is based on the task estimates from the sprint backlog. Add to it a new burndown chart, which will be based only on the number of tasks in the sprint backlog, regardless of their estimates. The new burndown chart can be called a task-based burndown chart.

Your familiar work-based burndown chart starts with the total of all task estimates for the sprint and, as estimates are updated daily, the burndown continues to reflect the estimated amount of work left in the sprint. Hopefully it will usually trend down toward zero. Your new, task-based, burndown chart starts instead with the total number of tasks listed for the sprint. Estimates aren’t updated for this chart, and work is burned down when a task is completed (its value on the burndown goes from 1 to 0). For best results, make sure your task breakdown results in the smallest tasks possible. The task-based burndown chart reflects the estimated total number of tasks left to do in the sprint and not the estimated work effort left. This works best if you have lots of small tasks, typically ones that can be done in a day or less.

Make sure that both burndowns agree and that both give you the same visibility into your progress during the sprint. If you find that the task-based burndown isn’t useful, take a look at Step 3.

Step 3: Shrink Tasks to Improve the Task-Based Burndown

A good, informative, task-based burndown chart depends on there being many small tasks to burn down. Conceptually, if you only had one task per product backlog item on a sprint backlog, you could have a perfectly good work-based burndown chart because the daily updates of the task estimates are given with arbitrary granularity (Now, if your product backlog items really have only one task each, it’s indicative that there is a problem with either your stories or your task decomposition). In contrast, the task-based burndown chart for this sprint would be very insensitive on a daily basis, because the tasks would tend to span many days, and progress would not show until a task was completed. The remedy is to make tasks small. A good rule of thumb is that a task should be something that can be completed in a day or less.

Step 4: Stop Doing Task Estimates

When your two burndown charts convey similar information and when you can deliver on velocity-based sprint commitments, you can stop doing task estimates and do away with the work-based burndown. For some teams this will be easy to achieve and for others it could take many sprints. The key to this is to use the idea of velocity correctly. Note that you will still want to be doing the task breakdowns for now. Eliminating them is a different step altogether.

What did we lose when we did away with the task estimates? Task estimates support planning needs four and five from the list above. We still have a burndown chart that we can use to track progress, so we still support goal five. We have removed the need to support goal four because our team has demonstrated the ability to make commitments based on story point estimates of product backlog items and does not need task estimates for validation.

The only thing we might have lost is tangential support for planning need number two. That is, by not asking for estimates, we may have removed some of the mental pressure and motivation to think deeply, look for issues, recall similar efforts, and in general actively bring knowledge and experience to bear on the problem of correctly planning out the tasks. How big a deal is that? The answer to that question is unique to you and your team.

Related Article

Article: The Trouble with Sprint Burndowns