Evidence-Based Scheduling

Those who ignore history are doomed to repeat it

Most estimates rely on someone’s gut sense made of three parts experience and one part eye of newt. The problem is that this estimation method has only a single piece of data (even if backed up by years of hoary experience, and a mass of battle scars). Each of these estimates is a possible point of failure. Multiply this point of failure by the number of cases you have and then by the number of members on your team and suddenly you have possibly hundreds of problem areas.

Some of these points are trivial, but some of them are absolutely crucial, which means your project is rotten with risk, and all of it hidden from your sight.

You need to get all of this hidden risk out into the light.

By contrast, Evidence-Based Scheduling (EBS) uses your actual estimation history to figure out how reliable you are. Developer history makes the hidden risks plain and clear for everyone to see.

The Raft of the Medusa

Doubt is uncomfortable but certainty is ridiculous

Traditional methods of estimation promise a specific delivery date, but we all know this is an illusion. It’s fake certainty. It feels good at first, but when it goes wrong it feels very bad, very bad indeed. What we need is a way to assess how we’re actually doing at any given point during the project.

This is where probability comes in. Using the developer’s actual estimation history EBS can assess the actual chance that you’ll be done on a given date. We don’t just add hours of estimates together and assume a completion date. We do thousands of simulations of different development scenarios to arrive at a probability for completion. This is far superior to the traditional method of hope and crossed fingers masquerading as certainty that most tools use.


Hit a target from two years away

It sounded a little crazy even to us, but we embarked on a two year release for FogBugz 7 a couple of years back. We rewrote the existing code base in .NET, and added an array of new features for the next major release of FogBugz. It was a massive project.

We set a date for delivery almost two years from when we started, and we shipped within two weeks of our original plan. No soothsayers were involved; we just constantly used EBS to adjust the project. It let us reassign work, drop a few features, pare some others back, and always, at every step, we knew the probability of shipping on our target date.


How it works

We take the actual estimates of the developers and run a Monte Carlo simulation against a randomly chosen velocity from their history. We do that one hundred times for each estimation to get a probability of its actual completion time. We do that across all cases estimated for your project and arrive at the most realistic schedule available. This process takes all the hidden risk, poor estimates, single points of failure—all the usual things that derail your schedule—and gets them out in the open so you can make well-informed and clear decisions about how best to manage your project.