Evidence Based Scheduling and FogBugz 6.0
- Share
-
- |
Read later
Reading List
A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.
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:
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.
3
Discuss
- 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.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.
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?
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:
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.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Related Sponsor
Deploy and manage industry leading databases in minutes. Our platform comes with high availability, auto-scaling, auto-backup and more. Free to try.
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
The Basis for EBS
by
Geoffrey Wiseman
Posted
We have been using it with our project for last one year
by
Fucked Up
Posted
Re: We have been using it with our project for last one year
by
Ben Hughes
Posted
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.
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.
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
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
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?
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?
