Sprint Capacity Planner

Sprints do not fail in week two; they fail in the first hour, when scope gets matched against a headcount fantasy instead of the actual calendar. This skill computes capacity from named people and real days — leave, holidays, meetings, support rotation, carryover — then fits scope to that number with a visible commit line, so the plan is an agreement rather than a hope.

When to use this skill

• Planning any sprint or fixed-length iteration for a team of two or more
• The last several sprints ended with rollover and nobody can say exactly why
• A sprint spans holidays, major leave, a release freeze, or an on-call-heavy week
• Leadership asks what the team can absorb this cycle and deserves arithmetic, not instinct

Workflow

1. Roster the sprint by name and by day. For each person: working days in the window, minus booked leave, public holidays, training, and known interview or event load. People-days, per person, written down where everyone can see them.
2. Apply an honest focus factor. Meetings, review churn, questions, context switching — teams reliably get 60 to 75 percent of a day as project work. Use last sprint's measured reality if you have it; use 0.7 if you do not. Never use 1.0, which is a lie with a spreadsheet.
3. Reserve the interrupt tax off the top. Support rotation, production issues, urgent small asks: measure the last three sprints' interrupt load and reserve that much. If someone is on-call, count them at half or zero by policy — decided now, not renegotiated mid-incident.
4. Charge carryover first. Unfinished work from last sprint is not new scope; it consumes this sprint's capacity before anything else gets planned. If carryover exceeds a third of capacity, stop and fix sizing practice before planning more inflow.
5. Fit scope to the remainder. Pull items in priority order, sized by the people doing the work, until the remainder is spent. Respect skill shape: four people-days of front-end capacity do not cover a ten-day back-end migration, whatever the total says.
6. Split commit from stretch. The commit list fits inside computed capacity and is the only thing reported upward as promised. Stretch items are named, ordered, and explicitly unpromised.
7. Write the sprint goal as one sentence describing the user-visible or business-visible change. If the committed items cannot be summarized in one sentence, the sprint is a grab bag — regroup it until it has a spine.

Worked example

Five people, ten working days: 50 raw people-days. One person takes three days of leave (-3); one public holiday hits everyone (-5): 42. Focus factor 0.7: 29.4. Interrupt reserve, measured at four days last sprint: 25.4. Carryover, two items totaling five days: 20.4 people-days remain for new work. Commit line drawn at 19 days of scope, leaving slack; six further days queued as stretch. The team promises 19 — not 50 — and hits it.

Output format

The capacity worksheet showing the arithmetic (roster, focus factor, reserves, carryover, remainder); the commit list with sizes and owners; the stretch list, ordered; the sprint goal sentence; and an assumptions log recording what was reserved and why, so the retro can audit the model instead of assigning blame.

Quality bar

• Committed scope sits at or under computed capacity — under, when estimates are soft
• Every number in the worksheet is auditable: named leave, measured interrupts, builder-owned sizes
• Stretch work never silently migrates into the commit report mid-sprint
• The goal sentence names an outcome, not a list of ticket numbers
• Next sprint opens by scoring this sprint's arithmetic against what happened; the model improves or it decays