Software effort estimation is an important part of the daily lives of many software professionals. I have joined the #noestimates debate on Twitter because there is a lot to learn from a discussion on estimates. I’m not ready to fully abandon estimates but I am interested in discussing where, when and how to apply them — or not…
Software Effort Estimation Problems
[bibshow]
Even though software effort estimation is so important for many software developers there has been very little progress in the last thirty or forty years. The accuracy and software effort estimation problems remain largely the same. What are the major reasons for the problems? Magne Jörgensen summarizes the software effort estimation problems in an article in IEEE Software: [bibcite key=”citeulike:13251111″]
- The top reason for overruns — client expectations of low cost. To quote one client: “You’ve estimated 100 hours for this feature. It is only worth 50 to me. Please adjust your estimate accordingly!”
- Estimators are unable to give “90%” high-low intervals for estimates.
- Expert estimators are easily mislead by irrelevant information.
Software Effort Estimation Remedies
What can be done about these known problems? Magne Jörgensen suggests three things to do: [bibcite key=”citeulike:13251111″]
- Use checklists and historical data. This is where your Definition of Done (DoD) comes in handy.
- Combine independent data. Easiest way to achieve this is through planning poker.
- Estimates should be avoided if they are not really needed. Estimates have a tendency to become self-fulfilling prophecies. This is perhaps caused by an unability to differentiate between estimates and commitments. [bibcite key=”citeulike:13251133″]
Source: Improve IT on Flickr | CC BY SA 2.0A team estimating their next iteration using planning poker. What agile estimation units are they using? Will they avoid software effort estimation problems by using Planning Poker?
Conclusion
I’m planning to write a longer post on #noestimates and software effort estimation problems in a while. If you have any input simply leave a comment below or send me a message on Twitter.
References
[/bibshow]
Image sources
- A team doing planning poker: Improve IT on Flickr | CC BY SA 2.0
- Coding Shots Annual Plan: Mathew (WMF) through Wikimedia Commons | CC BY SA 3.0
I think there is a more accurace assessment from @robpaller at https://twitter.com/RobPaller/status/530689621554778112
Definition of Done is a good start in that is better than arbitrary targets. But is is not a necessary and sufficient condition if what RobPaller says is accurate. In my experience, Rob is right on the money.
If the Definition of Done is not a necessary and sufficient condition, then logically whatever is necessary and sufficient is the actual definition of done, right?
With a root cause, any and all suggestions have little hope of actually fixing the problems you have observed