≡ Menu
Pawel Brodzinski on Software Project Management

How Big Are Your Buffers?

Estimating work effort needed to complete a specific task is a tricky job. Being a project manager most of the time you don’t create schedules alone. You need help from developers, support engineers, quality engineers or whoever it takes. If you’re lucky your colleagues would use some techniques which improve their scheduling. Anyway you end up with a bunch of numbers.

What do you do with them? Do you take them as they are or you rather add your buffers before passing a project plan through to salespeople? I bet the latter.

We use buffers because:

We don’t trust wild guesses of our beloved developers.

We usually forget time we spend on (irrelevant) meetings, phone calls, writing emails and chatting with colleagues.

We can’t measure well how much time the team spends on context switching.

We expect some unexpected events.

Integration is always a bigger pain in the ass than it’s supposed to be.

We learn from the past and we can’t find there any example of too short schedules while there are plenty of deadlines we couldn’t meet.

Everyone does that.

Of course depending on situation buffers will differ. If a task is a low-priority one developers will probably get more interruptions than those who work on that super-duper project the company has signed last month. Your key developer who knows virtually everything about your main product will have to attend much more meetings than that hacker found in a basement in summer. One-developer project won’t need as much integration as this monster which consumed a half of your development team.

But the question is still valid. How big are your buffers? Which events are included in your initial estimates and which goes to the buffer time? How do you change your buffers in uncommon projects?

in: project management

2 comments… add one

  • yatsevsky December 11, 2008, 3:03 pm

    Usually we make laughs over multiplying developers estimate on “pi” number and in a more rare cases, on “e”. =))) But usually buffer is 25-30%. What’s yours?

  • Pawel Brodzinski December 12, 2008, 3:32 am

    Depending on situation we use anything between -50% (yes, a negative buffer) to 100%. A negative buffer is when a salesperson come and say:
    – Hey, they won’t buy it with that schedule.
    We answer:
    – Hey, we won’t deliver much faster.
    – What can we do?
    – You know, we can cut the schedule but it won’t make us deliver faster. Then you and I will have to go to the customer and tell qhy we’re late.
    – That’s a good plan. Do it.

    For pure development tasks we use usually something between 20% and 30%. It can be modified (increased) by factors of “freshness” of a developer, poor track record in estimating, a high number of expected interruptions etc.

    Sometimes we use rough scheduling technique when we use 100% buffer but we include testing and implementation in buffer. This we do usually for standard tasks which we don’t expect much uncertainty in (change requests etc).

Leave a Comment