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
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″]
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.