Evidence Based Scheduling and FogBugz 6.0

Joel first wrote about scheduling on his blog in March 2000. The issues he focused on then are as prevalent now in both traditional and agile software development teams, mainly:

• The difficulty of tracking the accuracy of estimates until its too late.
• The tasks in a plan must be fine grained.
  
• The general belief that a schedule of work goes out of date from the minute the ink dries.
• The lack of will for software developers to make a schedule.
  

This [scheduling] is something almost no programmer wants to do. In my experience, the vast majority just try to get away with not making a schedule at all. Of the few that make a schedule, most are only doing it because their boss made them do it, half heartedly, and nobody actually believes the schedule except for upper management, which simultaneously believes that "no software project is ever on time" and in the existence of UFOs.

So why doesn't anybody make a schedule? Two key reasons. One, it's a real pain. Two, nobody believes that it's worth anything. Why go to all the trouble working on a schedule if it's not going to be right? There is a perception that schedules are consistently wrong, and only get worse as time goes on, so why suffer for naught?

Evidence based scheduling (EBS) attempts to deal with this by providing the team manager with a history of the accuracy of his team's (and individuals') estimates to provide a forecast of probability of hitting a date. It also encourages the teams to plan in small tasks (up to 16 hours) rather than week long tasks, leading to historical factually based data on the team's velocity.

You gather evidence, mostly from historical time sheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date.

What's new in Joel's approach is the application of the Monte Carlo method for generating probability statistics, enabling historical information of a developers accuracy in estimating to be included in the forecast delivery date. The results of this can be plotted on a graph to provide PM's with a visual indication of when the project is likely to deliver:
There is evidence to show that this technique is being seriously used in the field, and with its recent inclusion into FogBugz 6.0, the adoption is likely to continue. However, the approach does rely on fine granularity of task management, and requires a more controlling approach to team management - a move away from the facilitative self organising teams preferred in Agile approaches.

Do readers have any experience of using EBS in their teams? If so how have the results measured up against the reality?

FogBugz 6.0 is available as either a monthly hosted service, or as a self hosted option.