One of the most complex parts of Software Development is effort estimation. Over the years, I encountered some interesting concepts and laws regarding this topic that I would like to share. Being aware of these mechanics helped me to interpret and make estimates.
Here we go...
1. Accuracy vs. Precision
Probably the most important topic on the list.
Precision is how close measure values are to each other, basically how many decimal places are at the end of a given measurement.
Accuracy is how close a measure value is to the true value.
Precision is independent of accuracy.
Estimates should be accurate, not precise. It’s fine to say something will take two to six weeks. Most likely that's accurate, although not precise. Being more precise often leads to being less accurate. I challenge you to make a significant accurate estimate with minute precision 😉
2. The "Scotty Principle"
From How to Inflate Tasks and Extend Due Dates
If you're not a Star Trek fan, you may not be familiar with the Scotty Principle, but it's fairly simple. When asked how long a job will take, estimate the time required to complete the job, add about 25%-50% onto that estimate, and commit to the longer estimate. Then, when you deliver ahead of schedule (or something else happens that throws you off, and you're forced to deliver on schedule instead of ahead), you're a miracle worker who really knows how to get the job done.
On top of that, the Scotty Principle is often amplified as it echoes through every level it passes (Developer -> Project Manager -> ... -> Sales). This is because every level is unaware of the buffers added by others. Everyone in the chain can apply this principle on top of each other. So besides the developer, the project leader and sales guy can also add an extra 25% to 50%. Being unaware of additional safety nets, each creates its own on top of the others.
In the end, a one-week job could end up estimated as an entire month.
3. Parkinson's law
From Wikipedia, Parkinson's law
Parkinson's law is the adage that "work expands so as to fill the time available for its completion".
Take a minute to sponge this 😰. If you combine the Scotty Principle with Parkinson's law, the result is a zero-sum game. It's even worse! Due to Parkinson's law you somehow managed to eat up every buffer to finish just in time... what did you do with all that extra time 😏 !?
4. Unfounded Optimism
From: Software Estimation: Demystifying the Black Art
Optimism assails software estimates from all sources. On the developer side of the project, Microsoft Vice President Chris Peters observed that "You never have to fear that estimates created by developers will be too pessimistic because developers will always generate a too-optimistic schedule". In a study of 300 software projects, Michiel van Genuchten reported that developer estimates tended to contain an optimism factor of 20% to 30%. Although managers sometimes complain otherwise, developers don't tend to sandbag their estimates—their estimates tend to be too low!
What to do with this? Should a manager be so gentle as to add another 30% on top of your estimate to counter this? Maybe he's already doing this (without telling you)?
5. The Cone of Uncertainty
From Wikipedia, Cone of Uncertainty
In project management, the Cone of Uncertainty describes the evolution of the amount of best-case uncertainty during a project. At the beginning of a project, comparatively little is known about the product or work results, and so estimates are subject to large uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then tends to decrease, reaching 0% when all residual risk has been terminated or transferred. This usually happens by the end of the project i.e. by transferring the responsibilities to a separate maintenance group.
Don't underestimate the power of uncertainty. At the start of a project, it could mean your estimate is four times off! So an estimate of one month could be finished in one week or in the worst case, it could take four months!
6. Estimates are non-negotiable
I can’t count the times someone immediately replied to my estimate with: “Could you finish it in less time?”
Seriously? Where's your trust!? You ask me for an estimation and now you think I just made something up?
Replies like those really irk me. Imagine I ask “How tall are you?” and you reply 69.5 inches. Wouldn't it be awkward if I replied “could it be a bit smaller?” 😦. Estimates are like body length measurements, non-negotiable.
Conclusion
There's a lot to tell about Software Estimation. I would say that it's a science on its own, one which I don't master. Nevertheless, I always keep these six concepts in the back of my mind when making estimations, which helps.
For further reading, I can recommend: Software Estimation: Demystifying the Black Art
Enjoy and until next time!
Top comments (0)