Evidence Based Scheduling

For quite some time now I have been extolling the virtues of using actual data to estimate schedules.

Back when I was a young-pup I worked in sales-support for a massive consultancy. Most of our developers and software architects provided estimates for our schedules, but occasionally we would borrow someone from another group, and this other-group had a system for creating estimates. That system took actual-hours for doing certain types-of-tasks, crunched some numbers, and produced an estimate.

I needed to take a different approach, because my managers wouldn’t use that system.

As a sales-support-guy I had access to all of our financials, and I knew what the loaded rates were. As a developer I had access to the source code. I knew how to do division. So I made my own average-times based off-of those figures. I used those averages for my estimates. I regularly updated them whenever a project completed.

I kept estimates for different metrics: hours-per-table, hours-per-form, etc. I then made a gut-instinct-call about which ones were most relevant for a given project. I multiplied those averages by the new project’s expected number of each item, and then I averaged those averages.

The guy-from-the-other-team’s estimate was always a little low. Mine was always a little lower than that. But it was usually twice that of many other developers’. Which means that many other developers were off by more-than-100%

So, yes, I really believe in using actual evidence to create estimates. In fact anything less than what I was doing isn’t estimating at all. It’s throwing a dart at a small board. A board called “My Career” or “My Project” or “My Business”. With a blindfold on.

How does one do evidence based scheduling? Please read Joel Spolsky’s Evidence Based Scheduling essay.

Please note that the Joel’s company sells FogBugz. Please consider evaluating FogBugz.