David Anderson has suggested that doing estimates is a waste (muda). David always stimulates a discussion, but in this case there seems to be confusion over the role of estimating as well as what is good and what is bad estimating.
There are many texts and articles on estimating. Estimating construction costs, estimating software cost and durations, estimating counter top installations, etc. I'll skip to the end and reference the estimating handbook I'm most familiar with. NASA Cost Estimating Handbook, 2004. This is a "way over the top" handbook. It is a cost estimating handbook. An equivalent schedule estimating handbook does not exist. But it contains many insightful process that we in the software development business need to learn and use. These include:
- Estimating is a probabilistic process.
- It is not a process that produces a single number. A single number is pretty much worthless
- No number can exist without a variance and an acknowledgment of the underlying probability distribution from which it was drawn.
- Estimates must have a "basis of estimate" (BOE) to be valid.
- A BOE is a "written justification for a project cost estimate and the basis (planning assumptions) by which the project manager can predict how changes in the project will effect the current plan and cost."
- Estimates must be connected to the technical and programmatic risk assessments.
- These "risk adjusted" estimates are the only materials used in the management of programs.
- With a risk adjusted number the management and stakeholders have not way to assess the probability that the numbers are valid.
- This removes the opportunity to assess the impact on the project if the numbers are wrong.
- Estimates comes from analysis of the technical and programmatic processes and their associated risks.
- Estimating requires analysis
- Analysis is part of the work process for developing the Basis of Estimate (BOE)
- They are inseparable
- David definition of analysis as the "separation of an intellectual or material whole into its constituent parts..." needs a better definition.
- Here's one... "The method of proof in which a known truth is sought as a consequence of a series of deductions from that which is the thing to be proved." No taking things apart, but putting things together to draw a conclusion. How much will this cost? How long will it take?
So What's the Point Here?
When the conjecture is made that "estimating is muda" there is a whole domain of experience left out of the discussion, starting with the repeated questions of how to determine - how long will this take and how much will it cost? This is the role of estimating.
Some Other Thoughts
Good estimating uses historical data. This certainly not the exclusive domain of agile - a conjectured. In fact the high ceremony process of CMMI IPPD make use of historical data in CMMI Level 4 and 5.
