There are a variety of ways you can use and interpret range estimates. Here’s the method I use which has worked well for me:
- Step One: Start with a list of the requested work to be done for that iteration.
- Step Two: Break these down into a list of small tasks.
- Step Three: For each task, give a happy estimate. This is how long you expect it to take if things go well.
- Step Four: For each task, give a sad estimate. This is how long you expect it to take if you encounter problems along the way.
- Step Five: Sum up all of the happy estimates. It’s pretty much impossible for the iteration to be finished in less time than this amount.
- Step Six: Sum up all of the sad estimates. This is a realistic upper bound. It’s very unlikely that the iteration will take longer than this amount.
- Step Seven: For each task, average the sad estimate with the happy estimate. Sum up these averages. This will be a relatively accurate estimate of the time it will take to complete this iteration.
Step two involves breaking down the business requirements into the corresponding technical tasks. Often there is a one-to-one correspondance, but sometimes not. Any task that feels like it could take half a day or longer is a candidate for breaking down into subtasks. Breaking large tasks into smaller tasks is one of the keys to better time estimates.How you think about sad estimates and happy estimates is important. The sad estimate is not a worst-case scenario. Worst case scenarios are unlikely, and you’ll just end up with an exaggerated time estimate that hides information. I think of a sad estimate as a likely bad case scenario and a happy estimate as a likely good case scenario. What I aim for is that 10% of the time, the task should be completed faster than my happy estimate and 10% of the time it should take longer than my sad estimate.
Note that the time estimates are hours of development time, not dates. They should not include the time for meetings or other non-development tasks.
Why Range Estimates Are Better
Single Point Estimates Hide Useful Information
There is only one piece of information in a single point estimate. There are three pieces of information in a range estimate. In addition to the happy and sad estimates, the length of the range is valuable information. It tells how much risk or uncertainty is in the time estimate. Why throw away this useful information?
Range Estimates Remove BiasSometimes programmers are overly optimistic in their estimates. Perhaps they are really excited about the task and their low time estimate reflects a positive, can-do attitude. Or maybe they are afraid that if their time estimate is too long, their pet feature will get canned.
Sometimes programmers are overly pessimistic in their estimates. Realizing that unexpected things can go wrong, they add in arbitrary buffers, like multiplying their initial estimate by two. Or if they are in a culture where time estimates are mistaken for commitments, they have a lot of incentive to inflate the estimate to avoid “failing” by missing it.
Single point estimates are subject to these biases. Furthermore, when looking at a single point estimate, you can’t tell whether it’s an optimistic or pessimistic estimate. Range estimates force both yellow hat and black hat thinking for every task, so the bias gets thrown out from the get-go.
I’ve used this successfully working one-on-one with a business founder, but I’ve yet to see range estimates used in teams. I’m eager to see this happen, but not hopeful, since many tools like PivotalTracker and Trajectory assume single point estimates.
I’ve made an example Google spreadsheet that sums and averages your range estimates automatically. Feel free to copy this spreadsheet and use it.
This article on range estimates is also useful reading.