At Agile 2010, Arin Sime gave a presentation on how to build a more accurate burndown. Arin started by asking how long does the drive to work take? Various answers were given (15 minutes, 8 minutes, 45 minutes, 20 to 30 minutes). Arin pointed out that some estimate were precise but might not be accurate (for example 8 minutes, but what if we hit traffic?). Other estimates were less precise but allowed for more accuracy (20 to 30 minutes). He mentions that single point estimates are a problem because we tend to be overly optimistic and use different methods or have different biases. He then presented a scenario and asked if we can build a CMS website within 2 weeks. Some answered simply yes or no while other asked for more info and then gave a range of 3 to 4 weeks. The point was that even though a range was a better answer, the original 2 weeks presented in the question created an anchor for the response and any answer will be close to that range.
Arin moves on to discuss Scrum and mentions how Scrum uses planning poker to generate a consensus group estimate, and how using story points ensure relative estimates. However, estimates are still a singe point. Range estimates recognize uncertainty, alleviates our tendency towards optimism, incorporates risk, allows for better financial projections, and better informs our bosses and clients.
Arin then demonstrates how he uses range estimates. Basically, he still uses planning poker with his team, but each team member now raises 2 estimates. The team still discuss differences between low and high estimates, but eventually settle on a range between the 2 estimates. On the sprint burndown chart, both the high and low estimates are tracked. A 3rd estimate (the 2/3 of range estimate) is also tracked. Now the chart shows an ideal burndown and a low and high deviation limit. The actual burndown should fall somewhere in between this range
Arin warps up by warning against some pitfalls of using range estimation. He mentions that not everything can be estimated using a huge range otherwise you will lose all credibility. Try to meet the ideal estimate and don’t use the high estimate as an excuse to miss deadlines. He also stresses on always using the range estimate and not slowly moving back towards relying on the single 2/3 estimate.
Arin provided the slide deck for this presentation at http://www.slideshare.net/o19s/range-estimation-in-scrum
