Iâ€™m going to teach you a surprisingly effective trick for estimating better, but first I need to talk about dressing up vacuum cleaners.
Ze Frank is a pretty creative guy, but what makes him really interesting to me is his ability to make other people creative. Itâ€™s what he does. He catalyzes creativity, frequently among those who donâ€™t consider themselves creative. And when he talks about how he does it, he talks about the value of constraint.
Asked to go and â€œbe creative,â€ he notes, most people shut down. So, instead, he asks for something more specific. He asked them to make a whole earth sandwich; they made a few. He asked people to send in pictures of vacuum cleaners dressed as people. He got 215. Constraining people, forcing them to solve a smaller problem, made them better at it.
Creativity isnâ€™t the only thing that benefits from constraint. Asking engineers (or, really, anyone) for â€œan estimateâ€ is basically akin to asking them to â€œbe creative.â€ They know what examples of the thing in question look like, they understand that itâ€™s a reasonable request, they just donâ€™t actually know how to get there from here, much less how to be accurate about it.
Back in the sixties, NASA and the US DoD were spending a great deal of money on engineering. They therefore took a keen interest in improving planning and estimation, not unlike the interest you might take if someone was setting all of your money on fire. Out of this interest sprung the mellifluously titled â€œPERT/COST SYSTEMS DESIGNâ€ which, on the subject of estimation, made this central observation:
If you ask engineers for 3 estimates (Best Case, Most Likely, Worst Case) instead of 1, you get different answers.
Thatâ€™s pretty exciting! Constraints get us different answers, and different answers mean more bits of information. If youâ€™re not convinced that this is brilliant, though, here comes some next level awesome: A (weighted) average of these 3 estimates is a better predictor of actual completion time than any one of them. Specifically
(Best + 4*Most Likely + Worst) / 6
turns out to work pretty well in the general case. These so-called “PERT Estimates” or “3-point Estimates” give engineers credit for their assessment of “most likely” by weighting it heavily, but still allow optimism and pessimism to pull the average. I dare you to argue with this graph:
Having 3 data points actually helps in other ways, too. It means you can more clearly quantify the uncertainty of a project by comparing best and worst case estimates, and watching to see if the distance between them shrinks over time. It means you can produce â€œoptimisticâ€ and â€œpessimisticâ€ schedules. And, most importantly, it means that everyone is saying the same thing when they estimate.
Best, Worst, Most Likely. Try it for your next project, and see how it works. As we finish Firefox 4 and start looking at what comes next, there will be plenty of estimation happening, and Iâ€™m keen to see us bringing more science to the table. This may not be the right model for us, or we may discover that the coefficients need changing in our version of the equation; thatâ€™s fine. That would actually be a great result. My interest isnâ€™t in pushing a particular tool, my interest is in getting better at planning, getting more awesome out to our users faster. I think we do that by looking for systems that have worked for others, and seeing how well they adapt to us.
And then we dress up the vacuum cleaners.