Do you need improved agile estimates? If your agile process is heavily reliant on effort estimates, then chances are that you need to have the best possible estimates. Are your estimates already as good as they can be or do you need improved agile estimates?
If you are like most people you will use some version of “planning poker” to obtain your agile effort estimates. Planning poker is the de facto standard for effort estimation in agile projects. Planning poker is an extreme version of wideband Delphi estimation. Delphi methods are based on experts giving independent estimates.
By the way, why does “everyone” use so-called Fibonacci numbers for planning poker? Turns out that using Fibonacci-style numbers for planning poker tends to lead to lower estimated effort [bibcite key=”citeulike:12883096″]. And we all know that actuals are often higher rather than lower.
Implications for Improved Agile Estimates
It would seem that a logical consequence of this is that improved agile estimates can be a result of improving the experts making the estimates! M Jorgensen of the Simula Research Institute in Norway suggests twelve ways to improve effort estimation in software engineering. [bibcite key=”citeulike:1585269″]:
- Evaluate estimation accuracy, but avoid high evaluation pressure.
- Avoid conflicting estimation goals.
- Ask the estimators to justify and criticize their estimates.
- Avoid irrelevant and unreliable estimation information.
- Use documented data from previous development tasks.
- Find estimation experts with relevant domain background and good estimation records.
- Estimate top-down and bottom-up, independently of each other.
- Use estimation checklists
- Combine estimates from different experts and estimation strategies.
- Assess the uncertainty of the estimate.
- Provide feedback on estimation accuracy and development task relations.
- Provide estimation training opportunities.
Follow up on Estimation Accuracy
Following up on estimation accuracy seems like a good idea. It is basically a question of keeping tracks of the estimate for X versus the (reported) actual for X. Systematic follow-up on that can lead to improvements in estimation accuracy. But there is a risk that such follow-up simply leads to improvements in the reported actuals. And that, I guess, is the point of “avoid high evaluation pressure”. No matter what you measure, you will get more of it. Joel Spolsky has a much better idea: evidence based scheduling.
Evidence Based Scheduling Leads to Improved Agile Estimates
Evidence based scheduling basically works like this: Create a set of tuples <estimator,estimate,actual>. These should be gathered automatically from your tool set. Then when estimates are given, you have new tuples like <estimator,estimate,_>. Now, Spolsky suggests using the previous estimates together with statistical bootstrapping to create a probability distribution. “If Alice thinks it’s going to take 10 hours and Bob thinks it will take 15 hours then it will take 20 hours.” Evidence based scheduling addresses issues 5, 6, 10 and 11 above. It should lead to improved agile estimates.
Your Agile Process Can also Lead to Improved Agile Estimates
Many of the other issues on Jorgensen’s list will also lead to improved agile estimates. All you have to do is to follow normal agile practies. 1 and 2 are addressed as part of the normal Scrum process. Especially now that “commitment” has been renamed “forecast”. 3, 6, 7 and 9 are more or less well solved by doing proper planning poker but we should not underestimate the value of other methods of getting a ball park figure such as parametric estimation. [bibcite key=”citeulike:7694706″]
Definition of Done
I am 99% certain that you already have estimation checklists! You probably don’t think of them as such. You know them by another name: Definition of Done. Having and caring for a definition of done might be one of the easiest ways of learning from your team’s experience and avoiding to forget things that should go into the estimates.
If you are following normal agile practices and doing planning poker you are already on your way to improved agile estimates. Two things you can try to improve your estimates even more:
- Use evidence based scheduling. But does your tooling support it?
- Care for your Definition of Done to keep it relevant and useful for you.