Jeff Atwood over at Coding Horror just wrapped up a series on Estimation and I noticed that although he made some great points, I think he left out one valuable point. Here's the story he begins with:
These calculations are typically represented in the form of Fermi Questions; the canonical Fermi Question is How many piano tuners are there in Chicago?
* From the almanac, we know that Chicago has a population of about 3 million people.
* Assume that an average family contains four members. The number of families in Chicago is about 750,000.
* If one in five families owns a piano, there will be 150,000 pianos in Chicago.
* If the average piano tuner serviced four pianos every day of the week for five days, rested on weekends, and had a two week vacation during the summer, then in one year (52 weeks) he would service 1,000 pianos.
* 150,000 / (4 x 5 x 50) = 150
* there are ~150 piano tuners in ChicagoFermi questions are interesting, because the actual answer to the question is secondary to the process of how you arrived at the answer. Did you guess? Or did you estimate?
Making a guess might get you closer, it might get you an exact answer, or it might lead you completely astray, but why is the process more important?
Most people would say that a series of guesses are likely to be worst than a single simple guess. If we were dealing with working with tolerances or margins of error, that'd be the case, but it doesn't apply here. In fact, it may well be the opposite… if you have a series of guesses, some could be high, some could be low and they could balance out.
The real strengths from the process comes from the fact that each assumption – yes, they're assumptions – can be corrected individually. If any one of them end up being incorrect, they can be replaced by facts which increases the overall precision of the estimate. It doesn't matter that any of the assumptions are incorrect or wildly off, just the value of being able to adjust and fine tune them over time becomes immensely valuable.
These same concepts can apply to all estimates. Quite a while ago, I used to say “site design – 20 hours”. Wow, pretty arbitrary, huh?
Now I try to break this down into functional blocks. The header, footer, info blocks, whatever and then go from there. Having information down to this level gives an additional level to adjust and monitor. And more importantly as certain assumptions prove to be true or false, future estimates and the overall total can be adjusted accordingly.
Since writing the first draft of this article, we estimated a relatively small project on a close deadline. By breaking the tasks down to easily estimated pieces, we were able to determine an overall estimate with quite a bit of confidence. In addition, we could see where tasks could be done in parallel and quickly determine a critical path. Sure, the process might take a bit longer, but an additional 20 minutes will save us hours as we near launch.