Two inputs to a sustainable commitment. Velocity asks what the team has historically delivered; capacity asks what's realistic this specific sprint, given holidays, leave, and other demands.
▸ Try the interactive toolVelocity and capacity planning are the two inputs to a sustainable sprint commitment, and they answer different questions. Velocity asks: what has this team historically delivered, sprint after sprint? Capacity asks: how much can this team realistically deliver in this specific sprint, given who's actually available?
Velocity is a historical average — a smooth forecast of typical output. But any given sprint is rarely typical: someone's on holiday, a public holiday falls midweek, two engineers are pulled into an incident. Capacity adjusts the velocity-based forecast for the reality of this sprint. Committing to your average velocity when half the team is away is how you set the team up to fail — the two inputs together produce a commitment that's both grounded in history and honest about the present.
Velocity — historical average points/sprint (the baseline forecast).
Capacity — this sprint's realistic availability (adjust for leave, holidays, on-call, other demands).
Commit to capacity-adjusted velocity, not raw velocity.
Treating average velocity as the commitment for every sprint ignores that real sprints vary enormously in available time — so the team chronically over- or under-commits.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Committing to raw velocity | Average velocity assumes a typical sprint; this one rarely is. | Capacity adjusts for who's actually available this sprint. |
| Ignoring leave & holidays | Committing full velocity when people are away guarantees a miss. | Capacity planning accounts for the real available time. |
| Sandbagging on bad weeks | Without capacity logic, teams over-correct and under-commit. | Capacity gives a defensible, honest number for the specific sprint. |
| Eroding trust | Repeated misses (or sandbags) damage credibility with stakeholders. | Honest, capacity-adjusted commitments are met reliably. |
Average the points delivered over several recent sprints. This is the historical baseline — what the team typically achieves in a normal sprint.
Count the real available time: who's on leave, public holidays, on-call rotations, known interruptions, time committed elsewhere. A 'full' sprint is rarer than teams assume.
Scale the velocity-based forecast down (or occasionally up) to match this sprint's available capacity. Committing to average velocity in a half-staffed sprint is planning to fail.
Make the sprint commitment the capacity-adjusted figure, not raw velocity. This is the number the team can actually hit — which is what keeps commitments credible.
Compare committed vs delivered each sprint and refine both the velocity baseline and the capacity assumptions. Predictability improves as the inputs get more honest.
A team's velocity averaged comfortably, so they committed to that average every sprint — including one where two of five engineers were on leave and a public holiday fell midweek. Predictably, they missed badly, and the miss read as a performance problem rather than what it was: a planning failure.
The team had used velocity (history) but ignored capacity (this sprint's reality). Adjusting the commitment for the actual available time would have produced a smaller, achievable target — and a met commitment instead of a missed one. The work didn't slow down; the plan had simply ignored that the sprint had far less capacity than average.
The deliverable is a sprint commitment grounded in velocity but adjusted for this sprint's real capacity — a number the team can actually hit.
| Input | Answers | Source |
|---|---|---|
| Velocity | What we typically deliver | Historical average |
| Capacity | What's realistic this sprint | Availability this sprint |
| Commitment | What we'll commit to | Velocity adjusted for capacity |
A commitment is only as credible as it is achievable, and achievability depends on both history and the present. Velocity supplies the first, capacity the second — use one without the other and the commitment is a guess.
The subtle point is that capacity planning is what keeps Agile commitments honest rather than aspirational. Velocity alone tempts teams to commit to their average regardless of circumstances, which works in typical sprints and fails in the many that aren't. By explicitly accounting for leave, holidays, and competing demands, capacity planning produces a number the team can actually meet — and consistently meeting commitments is what builds the stakeholder trust that lets a team operate with autonomy. Chronic misses, even when caused by ignored capacity rather than slow work, erode that trust just as fast as genuine under-delivery.
Average velocity assumes a typical sprint. Adjust for this sprint's real capacity.
Leave, holidays, and on-call are knowable in advance. Factor them in.
A miss from ignored capacity is a planning failure, not a performance one. Fix the planning.
Predictability improves as velocity and capacity assumptions get more honest. Keep tuning them.
Velocity (Tool 03) is one of the two inputs; this tool adds capacity.
Capacity-adjusted velocity is what the planning event (Tool 06) commits to.
Defending a realistic commitment against over-loading is part of the PM's in-sprint role (Tools 16, 17).
Met commitments connect to the influence and credibility themes of Module 6.
Imagine a team with a steady average velocity. Next sprint, one of four engineers is on leave and there's a public holiday. Roughly how should the commitment change from the average?
Then ask: if they committed to full average velocity anyway, whose fault is the inevitable miss — and what does it cost in trust?
If you scaled the commitment down for the lost capacity, you've grasped why velocity and capacity are two separate inputs — history sets the baseline, but this sprint's reality sets the number.