Buffer

Write down why a plan slipped and the reason is different every time. This cycle a payment outage ate a day. Last cycle an urgent request from a large customer took two. Before that a security review arrived with no notice. Item by item, every one of them is an exception. Stack ten cycles side by side and there has never been a cycle without one.

The exceptions arrive reliably, and plans get built on the assumption that they won't. A team calculates the hours five people have across two weeks and fills all of them with named items. The first outage pushes everything back by exactly as much as it consumed, and a weekend or the next cycle absorbs the difference.

For a long time individuals solved this privately. Work that would take three days got quoted at five, with the cushion tucked inside the estimate. The result is that nobody knows how much slack the team actually holds. Anyone reading the plan sees 45 person-days fully committed to work, while roughly 8 person-days of cushion sit scattered through it. Hidden slack also tends to get consumed. Given five days, most people finish in three and use the remaining two rather than handing them back, which is Parkinson's law operating at the level of a single estimate.

A buffer collects that slack out of the individual items and holds it in one place. It stops being hidden, and in exchange the decision about what goes into it gets made after the cycle has started rather than before.

Calculate the time available, leave a set percentage of it unassigned, and let unplanned work that arrives mid-cycle land there. The percentage comes out of past cycles rather than out of a preference. If unplanned work took an average of 15 percent of the last five cycles, that average is the starting point. Most teams settle between 10 and 20 percent, and teams that also carry outage response or inbound support questions sit above that range.

The subtractions happen in a fixed order.

1. Multiply people by time to get the raw total. Five people across two weeks is 50 person-days.
2. Remove absences already on the calendar. Three days of booked vacation and two days of interviews leave 45 person-days.
3. Multiply by the focus factor — the share of total time that actually reaches planned work, after recurring meetings, code review, and answering colleagues' questions are filtered out. At 0.7 that gives 31 person-days.
4. Subtract the buffer last. Holding back 4 person-days leaves 27 person-days to fill with items.

Reorder those steps and the same time gets removed twice or not at all. Apply the focus factor before removing vacation and you end up discounting the meeting hours of someone who isn't even there.

Keep the buffer as one block. Split into 0.8 person-days per person, it gets absorbed into individual schedules and turns back into hidden slack. Held in one place it stays visible, and if half of it is gone in the first three days, that's a signal to look at the rest of the cycle while there's still time to act.

Anything left at the end of the cycle disappears rather than carrying forward. What teams do instead is pull a deferred item in once it's clear late in the cycle that the room is going spare.

The most common place is sprint planning. The meeting opens with the total, the buffer comes off it, and the remainder is the ceiling for what gets committed. Picking items first and calling whatever is left over the buffer runs the sequence backwards, and done that way the buffer is zero every time.

On teams that run an on-call rotation the idea gets sharper. Whoever holds the rotation spends the week not knowing when an incident will arrive. Assigning that person half a normal load and leaving the rest open is a buffer applied to one person instead of to the team.

The same approach scales to a quarter. With six cycles in a quarter, a team commits to five cycles' worth of items and leaves one cycle open for whatever the quarter turns out to require.

Dates promised outside the team usually carry one too. If the calculation says six weeks, the answer given is eight. Those two weeks get managed internally as buffer while the outside number stays eight. Announce that the cushion exists and it fills with other requests almost immediately.

"We're holding 20 percent back this cycle, so we'll commit to 27 person-days."

The calculation produced 31 and the team is choosing not to fill 4 of them.

"The buffer is already gone and we still have a week left."

More unplanned work arrived than expected, and something on the list now has to come out.

"A plan with no slack in it slips the first time anything breaks."

Committing to every available hour makes delivery a matter of luck.

Pagedeck holds back 15 percent every sprint. Mia quotes the reduced number when planning opens rather than the raw one, and Theo picks items against that figure.

Last quarter the team tried removing it. A deadline was close, so for two cycles every calculated hour went to a named item. Both cycles finished in the low 70s as a percentage of plan, and the items that slipped carried into the following cycle, which then started already in debt. The rule since then is that the tighter the deadline, the less the percentage moves.

The most common reading is that a buffer is idle time. On a plan it's a column with nothing written in it, which looks like nobody is working. But the empty space nearly always fills. What fills it is outage response, an urgent customer request, or help for a neighboring team — work that couldn't be written down in advance, not work that didn't happen. Strip the buffer out on that reasoning and plans land in the low 70s as a percentage every cycle, and after a few rounds nobody outside the team believes any date it gives.

The second is assuming a bigger buffer is a safer one. More slack, less chance of slipping — the arithmetic feels sound. But hold back 40 percent and the items inside the remaining 60 percent get loose, and work expands to fill the time exactly as Parkinson's law predicts. Velocity, the average amount of work a team finishes per cycle, drifts down with it, so the next cycle's calculation starts from a lower number too. Keep the percentage close to what the record supports, and if it keeps running out, look at why so much unplanned work is arriving rather than raising the number.