Evidence Based Scheduling and FogBugz 6.0

Posted by Ben Hughes on Nov 29, 2007

Sections

Process & Practices,

Development

Topics

Artifacts & Tools ,

Tools ,

Agile Techniques ,

Agile ,

Estimating

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.

1. Back to top

   The Basis for EBS

   by Geoffrey Wiseman

   There are some environments where this could work well; in others, the assumptions behind the approach won't work. In most of the places I've worked recently, task assignments are not made well in advance, they're flexible, and often accomplished by two or more people.
   
   EBS is designed to work in an environment where work is clearly assigned, accomplished by one person, and can be assigned well in advance. If I were working in that kind of environment, I could see EBS being a useful feature.
   
   This is, of course, my opinion. Joel might spin it a little differently, but Joel's got opinions about how to build software, and sometimes that shows up in how his tools work.

   Reply

2. Back to top

   We have been using it with our project for last one year

   by Fucked Up

   I am Chetan Mittal and I work for a small Java/Rails shop (www.synerzip.com). We have been using EBS to calculate near-to-real estimates for newer projects. How we do it is -
   
   1) each and every task (small to big, direct to indirect) on a project is given a rough time estimate. If this project resembles to any previous project we have done before and shares 60-70% of tasks then we use near-to-real estimates (for tasks) derived from previous project.
   2) Suppose, we want to derive near-to-real estimates for a new project which doesn't resemble to any older one.
   a) ask developer to give each task, he/she is working on, a rough estimate
   b) make developer re-enter the actual time on the task he/she has worked for
   c) make developer to add reasons of the actual vs estimated varies @ 20%
   
   This process gives us a) near-to-real estimates so that we can quote real delivery dates b) gives us productivity stats for developers c) etc

   Reply

3. Back to top

   Re: We have been using it with our project for last one year

   by Ben Hughes

   Chetan,
   
   It certainly seems like your approach makes sense - how do the developers feel about divulging that information - is it a painful process?
   
   Also, what arena do you use for gleaning the information - a retrospective? One to ones?

   Reply