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.
For the full planning workflow this plugs into — goal, capacity, backlog walk, commitment — start with our complete guide to sprint planning in Jira.
Leave a Reply
Your email is safe with us.