There's a blog post from a few years back that has resurfaced The 5 Laws of Software Estimates. It's one of those posts that's heavy on opinion and light on principles. Time to revisit this ill-informed idea on why, what, and how we need to use estimates to make decisions in the presence of uncertainty.
| Law of Software Estimating | Fact of Software Estimating |
| Estimates are waste |
A waste for whom? Developers think they are waste, but it's not their money. To those paying the developers, estimates provide actionable information needed to make decisions:
|
| Estimates are non-transferrable |
Its claimed Software estimates are not fungible. Estimates are transferrable if you keep track of what you develop and codify those Features for future reference. I work in a domain where a Central Repiository is kept of all work performed and used to estimate other projects. This is called Reference Class Forecasting and done in all mature project management domains. This is basic business process improvement and part of any credible estimating process. |
| Estimates are Wrong |
Estimates are NOT Guesses This is a fundamental category error in knowledge. Assigning a meaning to a term that is incorrect. Either a lack of knowledge about estimating or a willful lack of knowledge about estimating. I suspect that later since every High School Statistics class introduces the notion of an estimate and the two attributes of that estimate
Define these before you start estimating, not afterward. We need to know the cost for the product is "at our below $1,200,000 with an 80% confidence would be a statement a CIO might make to a development team. Or we need to know you can produce that product for that cost "on or before" the end of the 2nd quarter. |
| Estimates are Temporary |
Yes they are, that's why the Estimate to Complete and the Estimate at Completion are continually emerging with new data, better models, empirical data from delivered. This is obvious to any mature estimating organization. |
| Estimates are Necessary |
Correct Businesses cannot make decisions about whether or not to build software without having some idea of the cost and time involved. So why even introduce the first 4 as LAWs, rather state the first 4 as dysfunctions that need to be removed to increase the Value of estimates. |
So before you go off and Stop Estimating, ask yourself - or better confirm that those paying you for your work - that there is no need to know how much it will cost to produce the Value asked for or no need to know when that Value will arrive with some degree of predefined precision and accuracy?
If there is NO need, then estimates likely don't need to be made for your project.
If there is a need for all the right business and technical reasons, then ignore the first 4 Laws, and learn how to make estimates in the presence of uncertainty for those whose money you are spending. To learn why these laws are wrong and how to fix them, and how to start making credible estimating in the presence of uncertanty that exists on all projects, read the books and papers here.
