Software Estimation: Demystifying the Black Art by Steve McConnell

Published on

January 01, 2019

Estimation should be treated as an unbiased, analytical process; planning should be treated as a biased, goal-seeking process.
In 1986, Professors S.D. Conte, H.E. Dunsmore, and V.Y. Shen proposed that a good estimation approach should provide estimates that are within 25% of the actual results 75% of the time.
The CMM (Capability Maturity Model) is a system defined by the Software Engineering Institute to assess the effectiveness of software organizations.
The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.
A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.
In the 1970s, Fred Brooks pointed out that “more software projects have gone awry for the lack of calendar time than all other causes combined”. A decade later, Scott Costello observed that “deadline pressure is the single greatest enemy of software engineering”. In the 1990s, Capers Jones reported that “excessive or irrational schedules are probably the single most destructive influence in all of software.
Managers and other project stakeholders sometimes fear that, if a project is overestimated, Parkinson’s Law will kick in - the idea that work will expand to fill available time.
The penalties for underestimation are more severe than the penalties for overestimation, so, if you can’t estimate with complete accuracy, try to err on the side of overestimation rather than underestimation.
DeMarco’s common definition of an “estimate” - the earliest date by which you could possibly be finished.
What top executive usually value most is predictability.
The only way to reduce the variability in the estimate is to reduce the variability in the project.
One implication of these variations among individuals is that you can’t accurately estimate a project if you don’t have some idea of who will be doing the work - because individual performance varies by a factor of 10 or more.
So, although I prefer other methods for estimation, I do recommend studying Cocomo II’s adjustment factors to gain an understanding of the significance of different software project influences.
The best estimation techniques for small projects tend to be ”bottom-up” techniques based on estimates created by the individuals who will actually do the work.
Extreme Programming is a highly iterative approach.
Scrum is iterative.
If you can count the answer directly, you should do that first.
When estimating at the task level, decompose estimates into tasks that will require no more than about 2 days of effort. Tasks larger than that will contain too many places that unexpected work can hide. Ending up with estimates that are at the ¼ day, ½ day, or full day of granularity is appropriate.
A technique called the Program Evaluation and Review Technique(PERT) allows you to compute an expected case that might not be exactly in the middle of the range from best case to worst case.
A standardized estimation procedure is a well defined process for creating estimates that is adopted at the organizational level that provides guidance at the individual-project level. Standard procedures protect against poor estimation practices such as off-the-cuff estimation and guessing. They protect against changing estimates arbitrarily because a powerful stakeholder doesn’t like a specific result. They encourage consistency of the estimation process.
The LOC measure is a terrible way to measure software size, except that all the other ways to measure size are worse.
The effects of compressing or extending a nominal schedule and the Impossible Zone. All researchers have found that there is a maximum degree to which a schedule can be compressed.
The consensus of researchers is that schedule compression of more than 25% from nominal is not possible.
For team sizes greater than 5 to 7 people, effort and schedule both increase.
In short, planning addresses “how” to conduct a project, and estimation addresses “how much” of a quantity to plan for.
Your most powerful negotiating ally in estimate discussions is not your estimate; it’s your ability to generate planning options that non technical stakeholders have no way of knowing that.