I'm currently reading Steve McConnell's new book, Software Estimation: Demystifying the Black Art. The section on individual expert judgment provided one simple reason why my estimates are often so horribly wrong:
If you ask a developer to estimate a set of features, the developer will often come back with an estimate that looks like this:
Feature Estimated Days Alpha 1.5 Bravo 1.5 Charlie 2.0 Delta 0.5 Echo 0.5 Foxtrot 0.25 Golf 2.0 Hotel 1.0 India 0.75 Juliet 1.25 Total 11.25 If you then ask the same developer to reestimate each feature's best case and worst case, the developer will often return with estimates similar to these:
Feature Best Case (days) Worst Case (days) Alpha 1.25 2.0 Bravo 1.5 2.5 Charlie 2.0 3.0 Delta 0.75 2.0 Echo 0.5 1.25 Foxtrot 0.25 0.5 Golf 1.5 2.5 Hotel 1.0 1.5 India 0.5 1.0 Juliet 1.25 2.0 Total 10.5 18.25 When you compare the original single-point estimates to the Best Case and Worst Case estimates, you see that the 11.25 total of the single-point estimates is much closer to the Best Case estimate of 10.5 days than to the Worst Case total of 18.25 days.
You'll also notice that both the Best Case and Worst Case estimates are higher than the original single-point estimate. Thinking through the worst case result can sometimes expose additional work that must be done even in the best case, which can raise the nominal estimate. In thinking through the worst case, I like to ask developers how long the task would take if everything went wrong. People's worst case estimates are often optimistic worst cases rather than true worst cases.
It's an eye-opening exercise. And I'm ashamed to report that I've always used single-point estimates when estimating my work. This is the starting point for many project scheduling disasters, something McConnell refers to as a Collusion of Optimists:
Considering that optimism is a near-universal fact of human nature, software estimates are often undermined by what I think of as a Collusion of Optimists. Developers present estimates that are optimistic. Executives like the optimistic estimates because they imply that desirable business targets are achievable. Managers like the estimates because they imply that they can support upper management's objectives. And so the software project is off and running with no one ever taking a critical look at whether the estimates were well founded in the first place
While it's impossible to give a perfect estimate, it's a good idea to start with the worst case scenario and extrapolate backwards to the best case.