BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or get video-only pass to recordings.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Evidence Based Scheduling and FogBugz 6.0

QCon San Francisco (Oct 2-6): Learn what's next from software leaders pushing the boundaries.

Evidence Based Scheduling and FogBugz 6.0

Bookmarks

Nov 29, 2007 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more
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.

Rate this Article

Adoption
Style

This content is in the Agile topic

Related Topics:

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • The Basis for EBS

    by Geoffrey Wiseman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

    Back to top
  • We have been using it with our project for last one year

    by Fucked Up,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

    Back to top
  • Re: We have been using it with our project for last one year

    by Ben Hughes,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

    Back to top

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT