skip to content

How do you plan a Sprint's capacity when historical velocity assumes a full team?

level: seniorimportance: should knowfreq 58%

answer

  1. History is not a promise
  2. Velocity describes; capacity constrains
  3. Count the person-days actually available
  4. Standing duties are a tax, not an exception
  5. Select against the Goal, not to a number

basics

~20 s

Velocity is history from past Sprints; capacity is what this particular Sprint can hold. Scale the historical range by the person-days actually available — holidays, part-time allocation, on-call and support duty — then let the Developers select against the Sprint Goal rather than filling up to a number.

solid answer

~40 s

Keep the two apart. **Velocity** describes what the team finished in past Sprints; **capacity** is how much of this Sprint's working time genuinely exists. Start from the velocity range, not its average, and multiply by an availability factor built from real person-days: public holidays, anyone on a part-time allocation, the on-call rotation, a support rota. Treat standing duties as a permanent tax rather than an exception each Sprint, because they occur every Sprint. Plan to roughly 70-85% of the result, leaving room for the work nobody can enumerate — change-review turnaround, a production question, the item that turns out harder than it was sized. Then select against the **Sprint Goal** first and fill toward the bracket second. A Sprint planned to its last story point protects nothing when the first surprise arrives.

code

pseudocode · 14 lines
pseudocode
AVAILABILITY  (five developers, a ten-day Sprint)

  nominal person-days      = 5 * 10            -> 50.0
  minus two public holidays  50.0 - (2 * 5)    -> 40.0
  minus one 60% allocation   40.0 - (0.4 * 8)  -> 36.8
  minus on-call rotation     36.8 - 1.4        -> 35.4
  availability factor        35.4 / 50.0       -> 0.708

FORECAST

  velocity, last four Sprints = 34, 31, 37, 29
  range                       = 29 .. 37
  bracket for this Sprint     = 0.708 * range  -> 21 .. 26
  plan to 70-85% of bracket, Sprint Goal items first

go deeper

for a junior

Be ready to say that velocity comes from past Sprints while capacity is about the days this Sprint actually has, and that holidays and part-time allocation reduce what the team can take on.

for a middle

Explain the arithmetic: nominal person-days, deductions for leave, part-time allocation and standing duties, a factor applied to the velocity range rather than to its average.

for a senior

Demonstrate production judgement. Show how you measure a standing duty instead of guessing it, why you plan below the calculated bracket, how you handle carry-over without double counting, and how you diagnose a team that repeatedly misses its selection.

for a principal

Own the systemic view. Be ready to argue for how much slack an organisation should fund, what a permanent support load really costs across several teams, and how to answer a stakeholder who reads planned slack as waste.

## Two different quantities that get confused **Velocity** is a measurement of the past: story points brought to the Definition of Done, per Sprint, over the last several Sprints. **Capacity** is a property of the Sprint about to start: how many person-days the team genuinely has, and therefore how much of the historical range is realistically available. The confusion is expensive in one direction in particular. A team that carried a 33-point average through four normal Sprints, then plans 33 points into a Sprint containing two public holidays and an on-call rotation, has not made an optimistic plan — it has made an arithmetic error, and it will discover it on the last day. ## Building the availability factor Work it out in person-days, not in percentages of feeling. 1. Start from nominal person-days: developers multiplied by the Sprint's working days. 2. Subtract whole days lost to public holidays and booked leave. 3. Subtract the fraction of anyone on a part-time or split allocation. 4. Subtract the standing duties — the on-call rotation, the support rota, a recurring stakeholder commitment. 5. Divide by the nominal figure to get a factor, then apply that factor to the **velocity range**, not to its mean. A worked example, from a team building a translation-agency portal on a six-week release cadence, planning the Sprint that lands just before its seasonal traffic peak: five developers, ten working days, so 50 nominal person-days. Two public holidays remove 10, leaving 40. One developer is at 60% allocation, removing 3.2 of their remaining 8, leaving 36.8. The on-call rotation has historically eaten 1.4 days per Sprint, leaving 35.4. The factor is 35.4 / 50 = 0.708. Applied to a velocity range of 29 to 37, the bracket for this Sprint is roughly 21 to 26 story points — not 33. ## The taxes teams forget - **On-call and support.** These are the ones most often treated as an exception, Sprint after Sprint, in a team where they have never once been absent. Measure what they actually cost and subtract them by default. - **Change-review turnaround.** Reviewing other people's work is real work and is invisible on the board. - **Hiring and interviewing load**, which lands unevenly and hits senior people hardest. - **A seasonal peak in the product itself**, where production questions rise for reasons the team cannot control. - **Onboarding.** A new joiner reduces capacity before increasing it, and adding people should never raise the forecast immediately. ## How the inputs move the two numbers | Input | Effect on velocity | Effect on this Sprint's capacity | |---|---|---| | Public holiday in the Sprint | None; history is unchanged | Direct reduction in person-days | | A developer leaves permanently | Invalidates the history; rebuild it | Reduction from this Sprint onward | | Definition of Done expands | Lowers future velocity genuinely | No direct effect; items simply cost more | | On-call rotation added | Lowers future velocity over time | Immediate reduction, every Sprint | | A new joiner starts | Do not adjust; wait for evidence | Slight reduction while they onboard | ## Selecting the Sprint Backlog Capacity produces a bracket, and a bracket is not a plan. The Developers select work against the **Sprint Goal**: what has to be true at the end of the Sprint for it to have been worth running. Items that serve the goal go in first; the bracket then says when to stop. Two disciplines keep this honest: - **Plan to about 70-85% of the calculated bracket.** The remainder absorbs the unenumerable. A Sprint filled to its last story point has only one way to absorb a surprise, which is to abandon the Sprint Goal — the single thing the Sprint exists to protect. - **Count carry-over once.** An item that started in the previous Sprint and finishes in this one contributes its full size in the Sprint where it met the Definition of Done, and nothing in the Sprint where it started. Re-size it only if what remains is genuinely different from what was sized. ## Failure modes to name in an interview The common ones are worth being able to list: using last Sprint's raw number over a holiday period; treating standing duties as unplanned exceptions every time; planning to 100% and calling the overrun a discipline problem; converting the capacity bracket back into per-person hour allocations, which quietly restores everything relative sizing was chosen to avoid; and raising the forecast the week a new person joins. Each one produces the same visible symptom — a Sprint that consistently fails to finish what it selected — and each has a different cause, which is why diagnosing it correctly is the senior skill here.

  • A carried-over item is added to the next Sprint at its original size. Is that right?
    Yes, provided it is counted once. The item contributes its full size in the Sprint where it met the Definition of Done and nothing in the Sprint where it started. Re-size it only when what genuinely remains is different from what was originally sized — for example when the hard part turned out to be finished and a small remainder is left. What you must never do is split the credit across both Sprints, which flatters both figures and corrupts the history.
  • Should a team plan to 100% of its calculated capacity?
    No. Plan to roughly 70-85% and leave the remainder for what cannot be enumerated: production questions, change-review turnaround, the item that proves harder than its size suggested. A Sprint packed to the last story point has exactly one way to absorb a surprise, which is to give up the Sprint Goal. The slack is not inefficiency; it is what makes the goal survivable.

saying these in an interview costs you the question

  • Uses last Sprint's raw velocity across a holiday period
  • Treats on-call and support as an exception every Sprint
  • Plans to 100% of calculated capacity every time
  • Converts the capacity bracket back into per-person hours
  • Counts a carried-over item in both Sprints
  • Raises the forecast the week a new person joins