Ten to twenty percent. That's the chunk of a sprint's capacity most teams running an interrupt buffer end up reserving for work nobody planned — a production bug, a customer escalation, a "can you just" request routed straight to whoever looks free. Teams that skip the reservation don't get zero interrupt work. They get the same interrupt work, minus the plan to absorb it.
The failure mode is familiar if you've ever closed a sprint and found half the committed items carried over. Someone asks what happened, and the honest answer is usually some version of "a few things came up." Those things were real. The problem isn't that they happened — it's that the sprint plan had no room built in for them, so every one of them came directly out of committed work instead of out of a reserve that existed for exactly this.
> A sprint plan that accounts for zero interruptions isn't an optimistic plan. It's a plan for a sprint that doesn't exist.
Why "just estimate tighter" doesn't fix this
The instinct when sprints keep slipping is to blame estimation — story points were wrong, velocity is off, the team sandbagged. Sometimes that's true. But if you've already tightened estimates and sprints still slip the same way, the problem usually isn't the sizing of the planned work. It's that unplanned work is competing with planned work for the same capacity, with no rule for which one wins.
Two different problems get treated as one:
- Estimation error — a story was sized at 3 points and took 8. You fix this with better reference stories and retro calibration.
- Interrupt displacement — a story was sized correctly at 3 points, but a production incident ate the two days it needed. No amount of better estimating fixes this, because the story was never the problem.
Teams that lump these together end up "fixing" estimation accuracy forever without the slips actually stopping, because they're solving for the wrong failure.
A framework for building an interrupt buffer that holds
1. Measure what you're already absorbing. Before setting a number, look back three or four sprints and tag how much work was genuinely unplanned versus planned. Most teams are surprised the number is already 15-25% — they just never named it, so it never showed up as a line item in planning.
2. Reserve capacity explicitly, don't hope it isn't needed. Pull that percentage out of the sprint before you commit anything else. If the team has 100 hours of capacity and interrupt work has historically run 15%, plan to 85 hours of committed work, not 100.
3. Set a triage rule before the sprint starts, not during the fire. Decide in advance who can pull something into the buffer mid-sprint — a lead, the PM, whoever is on support rotation — and what qualifies. "Production is down" qualifies. "A stakeholder wants an update today" usually doesn't.
4. Timebox anything that lands in the buffer. An interrupt that isn't timeboxed tends to expand to fill whatever capacity is left. Give it a cap, and if it blows past the cap, that's itself a signal worth raising, not quietly absorbing.
5. Track interrupt work separately at close, every sprint. If the buffer is never full, shrink it next sprint and give that capacity back to planned work. If it's consistently overflowing, the number was wrong, not the discipline.
The point of the framework isn't to eliminate interrupt work — that's not realistic for a team supporting a live product. It's to stop interrupt work from silently cannibalizing commitments nobody agreed to break.
Where this breaks down without a tool that shows it
A framework on paper only holds if capacity and interrupt work are visible on the same surface, in real time — not reconstructed from memory at the retro. This is specifically where sprint planning tends to fail in practice: the plan lives in one place (a spreadsheet, a sprint goal doc) and the interrupts land somewhere else entirely (Slack, a support inbox, a tap on the shoulder), and nothing connects the two until the sprint is already over budget.
In Spryn, capacity and committed scope sit on the same screen as you build the sprint, so an interrupt buffer is a real, visible line item rather than a mental note — you can plan to 85% of capacity on purpose and see it, not guess at it. When unplanned work does land mid-sprint, Spryn's forecast is capacity-aware, so a task added outside the original plan shows up immediately as pressure on the sprint rather than disappearing into the backlog until the demo. And because Spryn surfaces risk signals as soon as a task has been stale too long or scope is creeping past capacity — not just at sprint close — a buffer that's about to overflow gets flagged on day three, while there's still time to say no to the next interrupt instead of carrying three stories into next sprint.
None of that requires a separate interrupt-tracking spreadsheet bolted onto whatever you already use. It's the same board, the same capacity view, the same forecast — just one that was built to expect that sprints don't run in a vacuum.
What if interrupt volume is wildly inconsistent week to week?
This is the most common objection to reserving a fixed buffer, and it's a fair one — a team supporting a brand-new product might see interrupt work swing from 5% one sprint to 40% the next. The fix isn't to abandon the buffer, it's to make it a rolling average instead of a fixed number: recalculate it every sprint from the trailing three or four sprints rather than locking it in once. A volatile average is still a far better planning input than treating every sprint as if interrupts won't happen at all.
If the swings are large enough that even a rolling average feels unreliable, that volatility is itself worth surfacing to whoever owns the roadmap — it's usually a sign that support and project work haven't been separated into different capacity pools yet, which is a bigger structural fix than anything a single sprint's buffer can solve.
Self-hosted teams that want capacity, forecast, and interrupt signals running on their own infrastructure can see the full breakdown at spryn.io/pricing — the self-hosted license is a one-time payment with unlimited seats, so adding whoever's on support rotation this sprint doesn't cost anything extra.