Last week we talked about how easily estimates go wrong when you try to make giant ones up front, but they can also fail easily when you try to add up lots of small ones.
Once again, it comes down to simple math and how optimistic we are about our planning. If I were to ask you to estimate your grocery bill, it would probably turn out something like:
| Item | Estimated Cost | Actual Cost | Difference |
| Milk | $2.99 | $3.99 | -$1.00 |
| Bread | $3.99 | $3.59 | +$.40 |
| Cheese | $7.99 | $6.59 | +$1.40 |
| Tomato | $0.99 | $1.19 | -0.20 |
| Lettuce | $3.49 | $4.99 | -$1.50 |
| TOTAL | $19.45 | $20.35 | -$0.9 |
In this example, we are ninety cents over budget, which is only a (0.90/20.35) 4.4% budget overage. In software projects, running 4.4% over budget would be a victory!
Groceries are the real world, and estimates work differently there. For one thing, people have lots of experience in the real world and have an intuitive feel for the data. People tend to be more realistic than optimistic. In the above example, none of the estimates are right, but the over-estimates and the under-estimates tend to even each other out. The end result is a very accurate estimate.
In the 10th Annual report from the Standish Group, only 4% of developers over estimated their schedules. These results may be up for debate, but I would say that the trend is correct. Developers underestimate much more than than the over-estimate. This could be due to many reasons, including:
- pressure to create “acceptable” estimates
- lack of experience
- lack of expertise in the area to be estimated
- incomplete requirements or specifications
- missing details
- forgotten work
So unlike groceries, software has an overwhelming trend of underestimation. When all the estimates are added up, instead of evening out, they compound each other into one giant underestimate.
We have all dealt with the Grand Estimator, who hears a brief sketch of the project and declares “It can be done by X date!” We cringe because we know that 1) they are probably wrong, 2) they are wrong because they have no details behind their estimate, and 3) because we are usually the ones left with the ball after they make up a date and run of to their next project.
To escape that insanity, we try to use data to back up our dates. We have all seen it, and some of us have even done it. Many of us are guilty of the death by many small estimate. We list out all the work to be done, give each one an estimate, and total them. All this does if give you a false sense of security. Unlike the grocery store, the totals usually don’t work much better than the Grand Estimator.
Hello Scriptkitty 