When the Sprint Outgrew the Team: A Capacity Planning Story
A municipal services team — call them the Permits squad — came to us late in 2021 frustrated. They had adopted Scrum eighteen months earlier, half the team was now remote, and every sprint ended the same way: a pile of unfinished work rolled into the next one. Velocity charts looked busy but delivery felt stuck. The Scrum Master suspected the team was simply slow. The data told a different story.
What they were actually missing was honest capacity planning. The Scrum Guide does not prescribe a formula for it, but Sprint Planning explicitly asks the Developers to forecast what they can realistically finish. This team had been forecasting on hope. Pulling apart their last six sprints showed a team that consistently committed to about 40 story points and finished roughly 28. The gap was not effort. It was arithmetic nobody had done.
Where the hours actually went
We did a plain accounting of a single two-week sprint for one developer. Ten working days does not mean ten days of sprint work. Once you subtract the meetings, the support rotation, and the simple fact that people are not machines, the real number is much smaller — and in a hybrid setup, coordination overhead is higher, not lower.
Start from available days, not headcount. Two of six developers had vacation and a statutory holiday fell inside the sprint. That alone removed nearly 15% of the team's nominal time before any work began.
Subtract the ceremonies and the standing commitments. Daily Scrum, Planning, Review, Retrospective, plus a recurring stakeholder call ate roughly a day per person across the sprint.
Reserve for interruptions you know are coming. One developer was on production support that week. Pretending that slot was fully available was the single biggest source of carry-over.
Apply a focus factor, honestly. A realistic developer spends 60 to 70 percent of nominal hours on sprint work, not 100. Remote context-switching pushed this team toward the lower end.
When we rebuilt the sprint on those numbers, the team's true capacity landed near 28 points — exactly what they had been finishing. They were not slow. They had been planning a sprint that did not exist.
What we changed for the next sprint
Planned to demonstrated capacity (their real finished average), with a small buffer rather than a stretch target.
Made the support rotation a visible, subtracted cost in Planning instead of an invisible tax.
Defined 'done' tightly so a finished item was genuinely shippable, removing the hidden rework that masqueraded as new work.
Reviewed capacity each Planning session, because a hybrid team's availability changes week to week.
The result was not heroic. Over the next three sprints the team committed to less and finished nearly all of it. Predictability returned, the carry-over pile shrank to almost nothing, and — the part the Scrum Master did not expect — morale rose. People stopped ending every sprint feeling behind. Capacity planning did not make them faster; it made their plan match reality, which is the only forecast a stakeholder can actually trust.
The lesson generalizes well beyond one squad. A sprint commitment is a forecast, and a forecast built on nominal headcount instead of available, focused hours will fail on contact with a normal calendar. Especially with distributed teams still settling into hybrid work, the discipline is to count what you truly have before you promise what you will deliver.
If your delivery teams are over-committing and under-finishing, XNM's program & project delivery advisory can help you ground sprint planning in real capacity and rebuild predictable delivery.