Fog Creek Software
Discussion Board




Buffer Time in Schedules

I was just re-reading the Painless Software Schedules ( http://www.joelonsoftware.com/articles/fog0000000245.html ) article, and I'm wondering how others using Joel's method handle "Buffer Time?"

Do you have a buffer line item within each section of functionality (i.e., a time span of about 2 weeks or so)?  Or just one for the whole project? What method do you use to reduce the buffer time?  Reduce it once every few days based on how much tasks have overrun their original estimates?

Also, is anyone else out there using FogBugz to do their schedules? It appears that Joel has the time tracking features in there that match the method he outlines.

Dave
Tuesday, November 12, 2002

There is a derivative of Eli Goldratt's Theory of Constraints that applies to scheduling called "Critical Chain" scheduling.  This method provides a sound theory for allocating and managing "buffer time" and is well worth study.  The nice thing is that it's very easy to understand (once someone points it out) because it's logical and intuitive.  There are several books that cover this topic, but the best place to start is Goldratt's original:

http://www.amazon.com/exec/obidos/tg/detail/-/0884271536/102-1854524-9936957

It's a very short book and written in the style of a novel (like most of his books).  I've used this technique successfully for several years.

Anonymous Jonah
Tuesday, November 12, 2002

I happened to read the Goldratt book yesterday, it totally makes sense and at some point I will clarify that in my article. The short story is that the buffer should be at the end, not on each line item, to prevent various perversities in human nature (e.g.: people will tend to use all their buffer if it's in the line items).

Joel Spolsky
Tuesday, November 12, 2002

Sounds like I need to run out and buy that book. Thanks for the feedback, guys.

Dave
Tuesday, November 12, 2002

"The short story is that the buffer should be at the end, not on each line item, to prevent various perversities in human nature (e.g.: people will tend to use all their buffer if it's in the line items)."

Absolutely.

If your carrying out the project for a "customer" don't show the customer a plan with all the buffer at the end. (Unless they have as good an understanding of Critical Chain Scheduling as you do).  Their human nature will come with, amongst others :

1. If these people are competent in what they're doing why is there such a big buffer at the end ?

2. Am I paying 10-20 per cent over the odds ?

3. These people keep missing intermediate deadlines, how can I trust them to finish on time ? 

Peter WA Wood
Tuesday, November 12, 2002

As a project manager with very very little experience, I have found my biggest problem is that the dev leads who provide me input into my project planning tend to underestimate wildly how long a piece of code takes to write. As a rough rule it seems that testing takes twice as long as writing a piece of code. Writing the code takes twice as long as the dev lead thinks it will. And then dev leads totally forget about admin time developers need to answer the phone, time to provide code review or design review services to fellow devs and time to help QA testers set up and hunt down problems.

So all my buffer time seems to be too little! *frustrated look* I tend to put buffer time at the end of chunk of work and base the buffer time on how long the chunk was planned to take.

Oh, and my devs treat integration testing time as buffer time and don't do sufficient focussed integration testing. My dev leads encourage this approach.

Astarte
Wednesday, November 13, 2002

This is how we did plan our last project:

We started with an Excel sheet like the one described in Joel's article; however, instead of one "Orig Est" column, we used three columns: one for "Design and Implementation", one for "Testing and Bug Fixes", and one for "Documentation and Administration". The sum of them is our "Orig Est"; then, as in the original sheet, come the "Current Est", "Elapsed" (one per developer) and "Remain" columns.

The reason for this layout is that developers (including me) tend to forget about parts 2 and 3.  So, an estimation like "uhm, ... about 8 hours" can usually be be translated to "about 8 hours for designing and hacking the code, another 12 hours to write a decent unit test and fix that subtle display bug, and perhaps 4 hours to add comments, add a nice little item to the user manual, and do the CVS check in". Which gives 24 hours, usually a more realistic estimate. Being optimistic, we did _not_ include buffer time into our schedule.

PS: Plus, we saved the Excel sheets as HTML and checked it in into the CVS repository as well.

PPS: "And then dev leads totally forget about admin time developers need to answer the phone".
My advice: forget about admin time developers need to answer the phone. Developers should not be forced to answer phone calls.

- Roland
Thursday, November 14, 2002

*  Recent Topics

*  Fog Creek Home