Sprint Capacity Planning for Software Teams

Why teams overcommit, sprint after sprint

Overcommitment is rarely optimism about the work. It is arithmetic that starts from availability nobody has.

• Headcount is used as capacity. Four developers, two weeks, forty days. Nobody has forty days.
• Leave is remembered late. Someone mentions a holiday during planning, everyone nods, and the sprint total is not changed.
• Support is unfunded. The retainer tickets that arrive mid-sprint were never in the plan, so they are paid for out of the feature work.
• Yesterday's velocity is used as tomorrow's promise. Velocity is a measurement, not a commitment, and it was measured in a sprint with different people available.
• Part-time is rounded up. Four days a week becomes "basically full time" in the spreadsheet.

The calculation, in five subtractions

Start from the calendar rather than the team size, and subtract in this order. Doing it per developer matters, because averages hide exactly the person who is away.

Forty became twenty-two. That is not pessimism, it is the same team described accurately. Teams that plan against the first number and deliver against the second conclude they are slow. They are not slow, they are measured against a fiction.

Story points or hours?

Both, for different questions. Story points are good at relative sizing and terrible at scheduling. Hours are good at scheduling and terrible at estimating unfamiliar work. Agencies need both because they answer to two audiences.

The mistake to avoid is converting points to hours with a fixed exchange rate and then defending the conversion. Track the relationship, let it inform the next estimate, and do not promise it to a client.

Reserve capacity for the work you know is coming

Every agency running retainers has a stream of unplannable work: a P1 on Tuesday, a client question that turns into two hours of investigation, a deployment that needs babysitting. You cannot schedule the specific tickets, but you can absolutely predict the volume, because you have months of history.

Take the last three sprints, add up the hours spent on work that was not in the sprint at planning time, and reserve that percentage. Most agencies land somewhere between 15 and 30 percent. Booking it explicitly converts a recurring disruption into a budget line, and it stops the same senior developer from silently absorbing all of it.

Balance the load across people, not just the total

A sprint can be correctly sized in aggregate and still be undeliverable, because the work is stacked on one person. The classic case is the only developer who knows the payment integration, holding six tickets while two colleagues have room.

1. 1Fill per developer against their own capacity, not against the team total.
2. 2Look at who is over before the sprint starts. After the standup on day three is too late.
3. 3Treat a single-person bottleneck as a knowledge risk, and pair on one of those tickets deliberately.
4. 4If a reshuffle suggestion is available, treat it as a proposal to argue with, not an instruction. The tool does not know that one client is about to renegotiate.

Closing a sprint without losing work

Unfinished work at the end of a sprint is normal. Losing it is not. A close flow should roll unfinished tickets forward deliberately, with three decisions made explicitly rather than by default:

• Carry it. Still valid, still next. It keeps its history and moves.
• Re-estimate it. What is left is not what was planned. Change the estimate before it moves, or the next sprint inherits a lie.
• Return it to the backlog. It was not important enough to finish, which is information. Say so, and tell the client if they were expecting it.

Carrying work silently is how a backlog becomes a place tickets go to be forgotten, which is the same failure described in preventing stale tickets.

Does AI change the capacity maths?

Some, and less than the marketing suggests. Agents can take work off the queue — a planner reading the codebase, a coding agent implementing a change, a reviewer running tests — but every run still ends at a pull request that a human reads and merges. The review time is real and it belongs in your capacity.

The honest way to plan for it: keep human review time in the sprint, measure over a few sprints how much implementation time actually moved, and adjust from evidence. We wrote about the boundary in AI coding agents for software teams.