Solve your Task Estimation problem in Scrum

I’m often asked about improving the estimates of task hours generated during planning meetings. Years of waterfall development have taught us - if we improve the estimates we will do a much better job of tracking the sprint progress.

When this comes up I like to ask two questions:

• why estimate task size at all?
• what value do we gain improving our project tracking?

Why estimate?

We produce estimates to help us decide how many tasks we can fit into an iteration (aided by Velocity/Yesterday’s Weather). As a side effect our estimates help us discover wildly different expectations around a task - one person thinks it three lines of code while another sees a whole subsystem.

Why track progress?

We track progress so that the team can tell if its on track to meet its goal for the iteration.

Instead of trying to improve estimates I recommend that the team focus on ensuring all of the tasks are:

• Small - not larger than 8 hours work
• Well understood - any one on the team would feel comfortable grabbing any one of the tasks

Recently Jeff Sutherland has described something even more radical. On experienced teams, such his own at PatientKeeper or some at Google the time taken to estimate tasks in hours just wasn’t productive. Instead these teams tend to know how much work they can take on and just look at how many tasks they can get done a sprint. Sprint tracking has become a matter of looking at the task board and seeing where the bulk of the tasks are. In the sprint is 1/3 complete but over 1/2 the tasks haven’t been started, then you have problem.

So Jeff still recommends that teams new to Scrum estimate their tasks in hours - but experienced teams might take off the training wheels and not estimate hours a for few sprints. See how it feels. If it works keep it.

So instead of improving your estimates - kick the habit, give up the estimates in hours.