A sprint is not one hundred per cent features
In short
- Problem: sprints were planned as if all available hours went to new features, so support work and technical debt were invisible until they became incidents.
- Decision: split each developer sprint explicitly — planned work, a reserved share for support and buffer, a reserved share for technical improvement — and define which work is genuinely allowed to break the sprint boundary.
- Result: commitments stopped being fiction, and the argument moved from "why is this late" to "what are we not doing".
- Timeframe: three sprints before the numbers settled.
Context
Four development teams on a two-week cadence, delivering across a portfolio of live consumer products. Production traffic means support work arrives whether or not there is room for it.
The problem
The plan said the sprint was full of features. Reality said otherwise, and reality won every time. A bug report from a stakeholder, a broken feed from a provider, a question that turns into two hours of investigation — all of it landed inside a sprint that had no space allocated for it.
Two things follow, and both are worse than being late.
The first is that support work becomes invisible. It gets done — someone always does it — but it does not appear anywhere, so the story at the end of the sprint is “the team committed to forty points and delivered thirty” rather than “the team spent a quarter of its capacity keeping production alive”. One of those is a performance problem. The other is a planning problem. They get treated identically, and the team absorbs the blame for the difference.
The second is that technical improvement never happens. Not because nobody wants it, but because it is the only category of work with no deadline attached, so it loses every prioritisation conversation forever. Debt does not accumulate through negligence. It accumulates through a sequence of individually reasonable decisions.
Constraints
Commercial pressure was real and legitimate — these products make money, and the roadmap was not optional. Stakeholders were accustomed to mid-sprint requests being accepted, because they always had been. And the teams had learned not to push back, which meant I could not solve this by simply telling them to say no; that just moves the cost onto the people with the least authority.
What I did
Wrote the split into the operating manual as a number, not a principle. Each developer’s sprint capacity is divided: the majority to planned work, a reserved share to support and buffer, a reserved share to technical improvement. The exact figures matter less than the fact that they are written, visible, and used during planning rather than quoted afterwards.
The effect is arithmetic. If the team’s committed capacity already excludes support, then support arriving does not break the commitment — it consumes a slot that was set aside for it. And when support consistently overruns its slot, that is data about the system rather than a failure of the team.
Defined what may break the boundary. A written criticality scale, C1 to C4, with response windows. C1 means production down, revenue affected, or a legal obligation — and it requires Product Owner approval and visibility. Everything else waits for the next sprint.
This is the part that made the rest work. “Urgent” used to be a property of how the request was phrased. Now it is a property of the request.
Framed the metrics deliberately, and wrote the framing down. Commitment accuracy, velocity stability, defect escape rate, the ratio of planned to unplanned work, plus an anonymous team pulse check every few weeks.
Every one of those is a signal about the system, and the manual says so explicitly, because I have watched what happens otherwise. Velocity is not a productivity score. The moment it is used as one, teams inflate estimates, and you have destroyed the only forecasting instrument you had — permanently, because you cannot un-teach that lesson.
What did not work: I initially tracked unplanned work by asking teams to label it at the end of the sprint. Nobody remembered accurately. It only became reliable when the label was applied at the moment the work entered the sprint, as part of accepting it.
Result
Commitments became something you could plan around. Not because the teams got faster — they did not — but because what they committed to stopped including work that was never going to fit.
The conversation with stakeholders changed shape, which was the real prize. It is no longer “why is this late”. It is “this fits, this does not, here is what would have to move”. That is a conversation you can have with a commercial director without either side losing.
The technical improvement share is the piece I watch most closely, because it is the first thing that quietly disappears under pressure. Protecting it is a continuous act, not a settled decision.
What I would change
I introduced the split and the criticality scale in the same sprint. Two changes at once made it harder to see which one was doing the work, and if I had to defend just one of them I would have wanted cleaner evidence.
I would also have started the pulse checks earlier. By the time I had morale data, I had already made the changes that affected morale.