Reserving capacity for the unknown

A team I once ran shipped on a three-week cadence. One Wednesday in week one, three things landed in the same morning: a leadership P0 about a pricing change the go-to-market team needed shipped before quarter end, a production issue customer support had triaged for two days and now escalated to us, and the head of growth dropping into our channel to ask why the experiment we owed them was sliding. The team was already at full sprint capacity, so every option on the table broke a commitment to someone.

That morning is the failure mode every new EM eventually runs into, and the root cause is structural. In a fast-moving company, priorities come from many places:

• Engineering owns the roadmap.
• Customer support drives incident urgency.
• Growth defines its own deadlines.
• Leadership reserves the right to a true P0.

The clean version of this is one senior engineering manager whose call is full and final, with every priority routing through them. Larger, slower orgs sometimes have that person, because there is enough stability for one head to hold the full priority map. In a fast-moving company the role is rare and brittle: either the person cannot keep up with the pace and becomes a bottleneck, or the org grows around them and starts routing decisions through PMs, growth leads, and skip-level execs anyway. Most teams end up with four people who all believe they have veto power, and your job as the EM is no longer to wait for the arbiter.

If you accept that surprises are a property of the environment, the question becomes how much room your plan leaves to absorb one.

The first move most teams reach for is wrong: the per-task buffer, where you pad every estimate by 10 to 20 percent and trust that the cushion will still be there when you need it (it will not be). It is defensive and invisible, and it fails in both directions:

• Inward. Cushion buried inside an estimate disappears into the work. Pad a three-day task to four and it takes four, because nobody races an estimate they know is padded and finishing inside the pad earns an engineer nothing. By the time you go looking for the cushion at the end of the sprint, it has already been eaten during execution, and there is nothing left to pull.
• Outward. The cushion is not a thing you can point to and protect. It is smeared across every task estimate, so PM cannot see any of it, and neither can growth or leadership, and none of them will treat padding they cannot see as real when they come asking for room.

The mental model that fixed this for me is a bucket. Capacity is the bucket and work is the water: a planned sprint is what we have already poured in, and any incoming surprise is more water you are trying to add. People assume you can swap water out, pull a task to make room, but in practice the swap is expensive, because you are mid-flight on the bumped task, dependencies are already moving, and the team has to re-plan in the middle of executing. A bucket with room left in it absorbs the new water, and a full one forces a tradeoff every time.

The framework I run leaves a named line in the bucket that everyone, PM and growth and leadership included, can see. Reserve is a category of work in the plan rather than a margin on estimates. Martin Fowler made the case for planning this way years ago. What follows is two ways I have found to keep the idea from quietly dissolving.

The first is a sprint-level buffer with the breakdown written out. On a three-week sprint, each engineer has about fifteen working days, split:

• Nine days for planned task work.
• Two to three carved out as named reserve.
• Three to four absorbed by standups and the small coordination tasks that are not worth estimating.

I will name where the reserve goes: one day for adhoc leaves (each person on the team takes about one a month, so at least one in any given sprint is close to certain), and two days for adhoc work pulled in mid-sprint. Once you start naming the drains, the list grows:

• Interview loads when hiring is on.
• Onboarding cost for a recent hire.
• On-call carryover from last week.
• The code review queue.
• Cross-team unblocks.

You do not have to model these formally. Naming them is most of the work, because the buffer stops being a vibe and starts being a line item PM can argue with. A rolling average over a few sprints will tighten the number, and that refinement can wait.

The second is structural rather than per-sprint. We run a one-week mid-release after every three-week main sprint, so the full cycle is three weeks of planned work followed by one week of calendar reserve. The week absorbs:

• Spillover from the last release.
• Production issues that do not warrant a hotfix.
• Internal bugs.
• Tech debt.
• Small tech initiatives.

It is also the natural home for sprint retro, 1-1s, and next-sprint planning, which would otherwise eat into "real" sprint capacity and be the first things dropped under pressure. Every stakeholder knows the week exists, and nobody has to negotiate it back into the schedule each cycle, which is the part that matters.

Both of these will have weeks where the reserve goes unconsumed, and that is the arrangement working rather than waste. You do want a staged backlog ready for those weeks: low-priority production issues, bugs, crashes, well-scoped debt items. If a developer is freeing up ahead of time and the reserve is not being eaten, pull from there. Tech changes fast enough that finding good filler work is rarely the bottleneck. You do have to keep that backlog triaged and shallow, because once it accumulates into a junk drawer, people stop trusting what is in it and quietly stop pulling from it.

Negotiate the reserve before the surprise lands. Mid-incident is the worst time to argue with PM about whether the reserve is real, because by then everyone in the argument has something burning, and nobody concedes room while their own priority is on fire. The smallest version of the contract is a pre-agreed swap rule: if a P0 comes in, the lowest-ranked item in the current sprint bumps to the next one, automatically, without a meeting. You will not get every stakeholder to love the rule, but you only need them to acknowledge it once, in the calm.

The reserve line has no advocate of its own: PM comes to planning to argue for the product rows, growth argues for its experiment, support pushes the incident queue, and leadership will always speak for a true P0, so the buffer is the easiest line in the plan to cut, and cutting it upsets no one in the room. I treat defending it as a standing part of the job. Cutting the line does not make the surprises stop arriving. It only means the next one gets absorbed the expensive way, mid-flight, with the re-planning happening in the middle of the sprint.

---