I love this post; it conveys the feel of the experience so well. One of my big aha moments about estimation was a bit in McConnell's Rapid Development . He pointed out that most estimates get made with executives pressuring for short numbers. When you iterate a few times with that, you end up with the smallest number that developers can't absolutely prove is impossible. If you draw out a bell curve of probable comple…
I wholly agree with this, and feel that all project plans should be constructed to mitigate the very high risk of initial estimates. Too many project processes treat estimates as commitments with no backup plan when they (inevitably) go awry. I think a better approach would be to design your system around the idea that all estimates are suspect until proven otherwise, which of course leads to iterative approaches etc…
I agree you can't run a business without any idea when anything will ship. But to get a good idea when things will ship, you don't need estimates.
For example, in the Lean world there's something I've heard called "Disneyland scheduling". You break the project down into lumps. You maintain a queue of the lumps. You measure the average time from position X in the queue to being released.
Now you have a reasonable early warning system for when things will ship. Which is generally much better than what people have with most projects, which is a fantasy date.