In the past, I wrote quite a few posts on estimation techniques. Since then, nothing much as been going on. No new techniques have revolutionized the world. Nothing changed. In the end, it all comes down to breaking down the task to something manageable by your mind and keeping a track record of your estimates. I like function point counting, some may have other preferences.
Earlier this week, I was catching up on some article reading and stopped on Joel Spolsky‘s article on Evidence Based Scheduling. It was actually written quite a few weeks ago, but I couldn’t get around to reading much from my RSS feeds lately. Of course, the article is mostly a huge promotion for FogBugz, but there are some great ideas in there. Unlike my previous work, Joel’s article does not discuss how to actually make the estimates. Instead, techniques to determine how accurate the estimates really are and what are the probabilities of shipping on time based on past project data are proposed.
As for the estimation techniques, nothing new here:
- Estimation has to be made by the developer who will work on it
- Time has to be measured in hours
- Any task larger than 16 hours should be broken down
The truly brilliant ideas are how the various developer estimates are combined into a project estimate. Of course, you can simply add up the numbers, which will give something more decent than any guess a marketing person will ever give and will be quite accurate if all estimates are of a comparable accuracy. Evidence Based Scheduling calculates an independant velocity range for each developer. It basically says how good this developer’s estimates were in the past. Were they 3 times too short or half too high? Obviously, it won’t be constant at all times, so the value for the current project can be anywhere, but likely to be similar to the past. The estimates and velocities are then combined using Monte-Carlo simulations to test different scenarios. Run it a few hundred times and you will get a clear picture of what might happen.
Brilliant. Nothing less. The value really comes when you have multiple developers, which is not my case, but the idea does seem to scale.
EBS is actually one of the features of FogBugz, Joel’s software. It looks really fine and I decided to try it out. I don’t care so much about the bug tracking features, it does not really do it any better than those dozen of other commercial or open source alternatives, but that EBS does bring value. I opened an account of the On Demand service as a trial. I don’t want to bother installing it on my own server. Trying to figure out until which date the trial was open for, I actually found out that it was free for students and start-ups with a restriction of 2 users. Sounds like an extended trial to me, which is good, because 45 days is not quite enough to test out a system based on statistical analysis of estimates.
I don’t know how new this idea really is. It’s so simple, someone must have done it before. My guess is that no one could take it out to the world in a way that is easy to grasp.