Velocity and capacity planning

Velocity and capacity are not the same number. One is what you historically finished; the other is the time you actually have this sprint. Plan with both — and the humbler one wins.

Velocity and capacity are the two numbers that keep a sprint honest — and teams that conflate them overcommit sprint after sprint. Velocity is how much work you have historically finished per sprint. Capacity is how much time you actually have this sprint. They answer different questions, and when they disagree, the smaller one is usually right.

The distinction that gets missed

Velocity is backward-looking: average the story points your team completed over the last few sprints and you have a reasonable expectation for a normal sprint. It smooths out the noise of any single sprint into a planning baseline.

Capacity is forward-looking and specific to the sprint in front of you. Two developers on leave, a public holiday, a heavy on-call week, the all-hands on Thursday — none of that shows up in your velocity average, but all of it eats the sprint you are about to plan.

So velocity tells you what a typical sprint looks like. Capacity tells you whether this sprint is typical. Plan on velocity alone and every holiday-shortened or leave-heavy sprint blows up. Plan on capacity alone and you lose the calibration that stops you from wildly over- or under-loading a normal sprint. You need both, and where they conflict, trust capacity — it knows something the average does not.

Capacity in hours versus velocity in points — different units Capacity ≈ 120 h hours available Velocity ≈ 30 pts points delivered ≠ different units — you can't convert one into the other
Velocity is the historical average; capacity is what this sprint actually holds. When a holiday or heavy support week shrinks capacity below velocity, plan to the smaller number — the average does not know about the holiday.

Calculating capacity you can trust

Capacity is simple arithmetic that teams routinely get wrong by being optimistic. Start high and subtract honestly:

  1. Working days in the sprint × people. Your gross starting figure.
  2. Subtract planned time off — leave, public holidays, part-time schedules.
  3. Subtract standing commitments — the ceremonies themselves, recurring meetings, 1:1s.
  4. Subtract the support and interrupt load — on-call, production issues, “quick questions” that are never quick. If you run a support rotation, that person is not available for sprint work, so do not count them.
  5. Keep a buffer for the unplanned. Something always lands. A team that plans to 100% of its remaining time has planned to fail the first time reality intrudes.

What remains is capacity. The most common error is skipping steps 4 and 5 — the interrupt tax is real, and a sprint planned as if it will not happen is a sprint planned for a team that does not exist.

Velocity is a planning aid, not a scoreboard

This is the point where velocity gets ruined. Velocity works for exactly one purpose: helping a single team forecast its own future sprints. The moment it becomes a target to grow, or a stick to compare teams with, it stops measuring anything — because the easiest way to raise your velocity is to inflate your estimates, and everyone quietly does.

Story points are relative to one team’s shared sense of size. They do not transfer. Team A’s 8 is not Team B’s 8, so “Team A did 60 points and Team B did 40” is a comparison of two different rulers. Velocity is a planning aid, not a scoreboard — respect that boundary and it stays useful.

For how velocity is actually calculated, how many sprints to average, and how to handle a brand-new team with no history, see the velocity chapter in the estimation guide — it goes deep on the mechanics so this chapter can stay focused on planning. And if the estimates feeding your velocity are shaky, that is an estimation problem to fix in refinement, not in planning.

Putting both to work in planning

In the meeting, the two numbers play distinct roles. Capacity sets the ceiling: pull work until the estimate total reaches your calculated capacity for this sprint, then stop. Velocity is the sanity check: if your capacity-based selection is wildly above or below your normal velocity, something is off — either your capacity maths or your estimates — and it is worth a second look before you commit.

Practically: work out capacity first, use it as the hard limit during selection, and glance at velocity to check the result is not surprising. When capacity and velocity disagree because the sprint is short-staffed or holiday-shortened, take the smaller number and move on. Under-committing costs you a little slack; over-committing costs you the sprint goal.

Frequently asked questions

What is the difference between velocity and capacity?

Velocity is how much work a team has historically completed per sprint, measured in story points — a backward-looking average. Capacity is how much time the team actually has this sprint, after leave, meetings, and support load. Velocity tells you a normal sprint; capacity tells you whether this sprint is normal. You need both.

How do you calculate team capacity for a sprint?

Start from the working days in the sprint, multiply by the number of people, then subtract the honest deductions: planned leave, public holidays, standing meetings and ceremonies, support or on-call rotations, and a buffer for the unplanned. What remains is capacity. Most teams overstate it by forgetting the interrupt tax.

Should you plan to your full velocity?

No. Velocity is an average, so planning to it means overcommitting half the time by definition. Plan to your capacity for this specific sprint, sanity-checked against velocity. When the two disagree — a holiday-shortened sprint, say — trust capacity and take the smaller number.

Is velocity a measure of productivity?

No, and treating it as one breaks it. Velocity is a planning aid for one team’s own forecasting. The moment it becomes a target or a cross-team comparison, teams inflate estimates and the number stops measuring anything. Points do not transfer between teams.