Putting Task Estimates in their Place

June 7, 2008 CollabNet VersionOne

Let’s look at how a team makes use of task estimates. During Sprint Planning, teams create tasks and task estimates from the backlog items that they are potentially going to commit to finishing. Sometimes, these estimates have some effect on whether or not the team is actually going to commit to completing the backlog item, but most of the teams that I’ve worked with or interviewed told me that their team commits to backlog items based on what they “feel” they can accomplish, not based on the total hours that they’ve estimated so far. I coach this “how-much-does-it-feel-like” approach as well because I want a commitment based on the team’s willingness to commit, not one based on arbitrary mathematics.

How else do we use task estimates? Well, we update them every day – that’s where the Sprint Burndown comes from. The Sprint Burndown is a tool for the team to understand how much work we’ve gotten done this Sprint compared to how much we think is left. However, on a day-to-day basis, how much does the condition of the Sprint Burndown affect how your team members work? Do they work faster? I hope not – that’s when we cut corners on quality. Do they work longer hours? Again, I hope not – beyond a certain degree, individual team member performance will actually become worse. So, other than using the burndown to see if the team needs to de-commit something or take on a new story during the Sprint, the estimated remaining hours on each task is used to manage the commitment, not drive the work.

In fact, tasks only create a list of things to do, and tasks estimates serve little more than administrative purposes. Trying to gain an understanding of why some actuals were higher and some were lower will be scientifically impractical. What I mean, is that there are too many variables in play that effect how an individual and a team performs during a Sprint: individual skills, emotions, physical health that day, how focused they were, whether or not they manage a leap of intuition, etc. At the Sprint-level perspective, many of these “effects” average out; at the task-level, however, they are clearly in play. Rather than trying to figure out why your actuals were 12% off your estimates, do these three things:

  1. just ask your teams to commit to one or two fewer stories or one or two more stories next month,
  2. do not assign all of the tasks on the Sprint Backlog on day one. Team members should pick up the tasks they want when they are ready for the next task. They should break up into smaller teams, take the tasks they can do, and come back to the task board for more when they are ready.
  3. Use backlog grooming techniques to slice your backlog items into small pieces before the Sprint begins. Try to target getting items down to a size that two or three team members could finish a story in less than a week. That will improve the flexibility of your teams and will improve your teams’ ability to fine-tune their commitment from Sprint to Sprint.

Download the PDF version: Putting Task Estimates in their Place blog

Previous Article
Subversion 1.5 – Release Candidate 9 Available
Subversion 1.5 – Release Candidate 9 Available

Binaries of Subversion 1.5 - Release Candidate 9 are posted Read more ›

Next Article
Redeeming the Commons
Redeeming the Commons

One thing that's special about successful Open Source communities is that they have found a way to protect ...