October 2, 2011

Estimates are Not Commitments

  —The difference between an estimate and a commitment is worth remembering.

I am re-reading Mike Cohn's book "Agile Estimating and Planning". It's turning into a good opportunity to take a second look at the references. In chapter two, "Why Planning Fails", Mike references an article by Phillip Armour "Ten Unmyths of Project Estimation" published in the November 2002 issue of  Communications of the ACM.

Mike's main point for referencing the article is to link the idea that an estimate represents a probability of completing a project. It often becomes a commitment to an end date. I view this as a variation of the idea presented in chapter one "The Purpose of Planning" and what the concept of the cone of uncertainty teaches us.  The two reenforce the point that estimates are not 100% accurate.

If you are not familiar with Phillip's article I encourage you to read it. A couple of unmyths that I particularly enjoyed.

• The accurate estimate myth. Funny that people forget what an estimate really is!
• The lines of code myth. Hilliarious that people actually measure this to capture productivity!

I like the idea that the cost of software is associated with knowledge acquisition. Since people learn at a finite pace adding more people to a project doesn't make it faster and has the downside of parcelling
out the knowledge into smaller pieces so that no one really has the whole picture.

The main point of Phillip's article is that estimates are highly educated guesses. They are not exact and that is why it's called an estimate. This point drives home the fact that the only way to improve the probability of an estimate it to continually revise the estimate based upon new knowledge and information.

If that knowledge and information is used by expert estimators then you remain within the cone of uncertainty and are provided a higher level of assurance that the project is under control.