What is an estimate?
Estimation is one of the simplest, yet most frightening activities that software professionals face. … It is the primary wedge that has been driven between business people and developers. It is the source of nearly all distrust that rules that relationship.
— Robert Martin in The Clean Coder
What is an estimate?
Business people tend to view estimates as commitments; developers tend to view them as guesses; and the difference is profound.
“An estimate is a commitment.”
From the typical business person’s perspective, an estimate is a goal to be achieved. In this view, when a developer estimates a delivery date, he is essentially committed to produce certain deliverables by that date—anything else is dishonesty or incompetence. If on-time delivery requires the developer to work 12-hour days, on weekends, skipping vacations or holidays, then that’s what must be done in order to honor the commitment.
The business person is making plans based on these estimates, and he expects the developer to do his job in such a way that the plans don’t get derailed; for the cost of derailing such plans can be enormous!
From the business person's perspective, it's entirely reasonable to ask, "How long will that take, and what will it cost?" and to expect an answer, and to hold the developer to it.
"An estimate is a guess."
The typical developer, on the other hand, sees estimates as educated guesses. To him, no commitment is implied. He knows that nothing is certain in software development; that change is too frequent; and that he simply can't know enough before a project starts to accurately foretell how much it will cost in time or money by the end. There are just too many unknowns.
To the developer, the reason he gives estimates is because he can't know ahead of time how long something will take. Missed estimates are therefore not a sign of deceit or incompetence; rather they are a reflection of the inherent unpredictability within software development.
The truth: An estimate is a probability distribution.
Good estimates come with ranges and likelihoods; they are not just a number. For example, when a business person asks how long a feature will take, a bad estimate from a developer would sound like, "one week." A good estimate, on the other hand, might be organized into "best-case," "normal-case," and "worst-case" scenarios. It will sound something like, "If everything goes perfectly, this feature will be done in three days. If we encounter some obstacles (which is likely), it might take two weeks. And if there are lots of unforeseen difficulties, it could take a month or more."
A good estimate like this could be graphed, by comparing development times vs likelihood, like so:
