The capacity vs velocity sprint planning debate keeps resurfacing on LinkedIn, and it usually starts the same way: someone asks why their team’s sprints keep failing when they “only committed to velocity.” Half the replies say to plan against average velocity and stop overthinking it. The other half say velocity is a trailing indicator and only person-by-person capacity math tells you what this sprint can hold. Both camps are right about the failure they’ve seen — and wrong that you have to choose.
What each number actually measures
Velocity is historical throughput: the story points your team completed per sprint, averaged over the last three to six sprints. It bakes in everything that really happened — interruptions, rework, meetings, the works. That makes it an honest ceiling, but a backward-looking one. Velocity knows nothing about next sprint.
Capacity is forward-looking availability: who is actually in the sprint, for how many days, at what allocation. It catches exactly what velocity misses — the holiday week, the two engineers pulled onto an incident, the new joiner at half speed. But capacity in hours says nothing about how much work those hours historically convert into.
Why teams get burned picking one
- Velocity-only teams overcommit every sprint that isn’t average. An August sprint with three people on leave gets planned like a full-strength one, because “our velocity is 42.” The miss then pollutes the velocity average, making the next forecast worse.
- Capacity-only teams rebuild the plan from hours every sprint and drift into estimating tasks in hours — a slower ceremony that still misses the conversion rate between available hours and finished stories. (That trade-off is its own debate; see our take in story points vs hours.)
The two-step that works: velocity sets the baseline, capacity corrects it
The practical answer most experienced scrum masters land on is a two-step. First, take your rolling velocity as the default commitment ceiling. Second, adjust it for the sprint you actually have in front of you: compute this sprint’s capacity as a percentage of a normal sprint — headcount, days off, allocations — and scale the velocity number by that percentage. A team with a velocity of 40 entering a sprint at 70% capacity plans to roughly 28 points, not 40.
This is the step most planning ceremonies skip, because doing the capacity math by hand — per person, per day, across allocations and public holidays — is tedious enough that teams quietly stop doing it. It belongs on your sprint planning checklist anyway, right before the commitment is recorded.
Running the two-step natively in Jira
This is exactly the gap Sprint Planning, Capacity & Resource Planning for Jira closes. It reads each member’s availability — days off, part-time schedules, percentage allocations across teams — computes the sprint’s real capacity, and puts it next to your velocity as you pull stories in, so the “scaled ceiling” is visible during planning instead of being a spreadsheet someone forgot to update. Paired with a groomed backlog (its companion, Backlog Refinement for Jira, keeps the top of the backlog estimated and sprint-ready), the capacity-vs-velocity argument mostly dissolves: velocity proposes, capacity disposes.
The commitment question underneath
Notice what the two-step changes about the conversation with stakeholders. “We commit to 28 points” stops being a negotiation posture and becomes an auditable calculation: here is our historical throughput, here is who is actually available, here is the product of the two. When the sprint lands, the retro can inspect which input was wrong instead of relitigating the whole system.
One caveat on both numbers: velocity and capacity describe how much a sprint can absorb, not how long any single item takes to get through it. A team can hit its points every sprint while stakeholders still wait weeks for the thing they asked for, because the work sat in the backlog long before it was pulled. If that is the complaint you keep hearing, the missing measure is a clock rather than a count — see cycle time vs. lead time for which one to start, and DORA metrics in Jira for how those clocks feed delivery performance. And when the velocity number itself is what a retro is litigating, the velocity chart shows what it can and can’t explain about the sprint you just ran.
For the full planning workflow this plugs into — goal, capacity, backlog walk, commitment — start with our complete guide to sprint planning in Jira. For the Jira mechanics, from creating the sprint to running sprint planning in Jira against real capacity, use the step-by-step guide. And if the underlying distinction is still fuzzy, velocity vs. capacity: what agile teams get wrong covers it in depth.
