Velocity vs. capacity in Jira: which drives your Scrum sprint commitment?

Two numbers, two directions

Velocity and capacity both use story points, but they point in opposite directions:

Treating last sprint’s velocity as this sprint’s commitment ignores the main variable that changes every iteration: availability. That is why teams with stable velocity still miss forecasts when holidays, onboarding, or support load shift mid-quarter.

What velocity measures in Jira sprints

In Jira Software Cloud, the velocity chart shows completed estimates per sprint — usually story points on issues that reached Done by sprint end. The black average line is the mean across the sprints displayed.

Important constraints from how Jira builds the chart:

• Board-specific. Only issues on that board’s filter count. Another team’s velocity is not yours.
• Column mapping matters. “Done” means the right-most mapped column, not a label you use informally.
• Commitment vs. completed differ. The gray commitment bar is scope at sprint start. The green completed bar is what finished — including scope added after the sprint started. Comparing them shows forecast error, not just speed.
• More sprints, steadier average. Atlassian notes velocity becomes more useful as history grows; one or two sprints are a weak basis for a hard target.

Velocity answers “what happened?” It does not know that two developers are on leave this sprint or that a release will consume three days.

What capacity measures in Jira sprints

Capacity is a forward budget: how many story points of remaining work the team can absorb this sprint given real availability. It typically combines:

• Who is on the team for this sprint
• Working days per person (defaults and sprint-specific adjustments)
• Efficiency — the share of time available for delivery work after meetings and support
• Shared time off (holidays, team events)
• Carry-over load counted at remaining points, not always full estimate

Jira tracks story points on issues and sprint scope, but it does not model team availability or a live load-vs-capacity budget during planning. Teams either approximate capacity in spreadsheets or use a capacity model alongside Jira — see the sprint capacity guide for how ScrumNav approaches this.

Velocity vs capacity: which sets sprint scope?

The sprint commitment — the scope the team agrees to deliver — should match this sprint’s capacity, not last sprint’s velocity copied forward.

Velocity still matters as a sanity check. When your capacity model converts availability into story points, compare the result to average completed points from recent closed sprints. If capacity implies 45 points but the team has not exceeded 32 in the last four sprints with similar availability, resolve the gap before committing — wrong estimates, unmodeled carry-over, or optimistic availability are the usual causes.

Incomplete issues: velocity ignores them; capacity cannot

Velocity only counts issues that reached Done by sprint end. Tickets still in progress do not appear in the completed bar — but they still consume effort in the next sprint.

Capacity and planned load must count remaining work on carry-over, not always the full story point estimate. A 13-point issue that is 70% complete should add roughly 4 points of load, not 13. If you plan from velocity alone, you treat that ticket as “free” until someone remembers mid-sprint.

Example: average velocity is 36 SP. Three in-progress issues carry over with 9 SP of remaining work combined. Capacity for the new sprint is still ~36 SP, but 9 SP is already spoken for — room for new backlog items is closer to 27 SP before buffer. Velocity says nothing about that gap; capacity and planned load must.

Model completion in the capacity settings (status- or time-based). For the full carry-over workflow in planning, see how to plan a realistic sprint in Jira.

Worked example: same velocity, different capacity

A six-person team completed an average of 36 story points over the last three closed sprints. Sprint length is two weeks; default capacity assumed everyone at full availability.

Next sprint: two members are on holiday for three working days each (six person-days lost out of ~60). No new hires; estimation scale unchanged.

• Velocity-only planning commits ~36 points because “that is what we usually do.”
• Capacity-based planning reduces effective person-days by ~10%, yielding a budget near 32 points before buffer.

If the team still plans 36, the over-commit is structural — not a motivation problem. The fix is replanning scope to the lower budget, not pushing harder mid-sprint.

Where velocity shows up in Jira (and ScrumNav reports)

Jira does not label a single “velocity” field during planning. You read it from history:

• Jira velocity chart (board Reports) — completed story points per sprint and an average line across recent sprints.
• ScrumNav sprint reports — the Done SP / sprint KPI is average completed points (velocity). The Plan vs actual chart shows done SP per closed sprint. Capacity estimate is separate: velocity scaled by this sprint’s working time — your forward budget, not the historical average itself.

See the sprint reports guide for how teams use done SP and forecast error before the next sprint planning session.

When velocity misleads

Do not use average velocity alone as commitment when:

• Availability changed. Leave, part-time members, or on-call rotation reduced effective days.
• The team changed. New members, departures, or contractors alter throughput before history reflects it.
• Recent sprints were outliers. One release-heavy or incident-heavy sprint skews a small window.
• Carry-over was high. Completed points looked fine while unfinished work piled up — velocity masked load.
• Estimation scale shifted. Re-baselining story points breaks comparison with older sprints.

In those cases, capacity from current availability should override velocity. Use sprint reports to see plan vs. actual and whether past “velocity” was sustainable.

When velocity is a fair sanity check

Velocity aligns with capacity when the team is stable, estimation is consistent, and recent sprints had normal availability. Then average completed points should sit close to what your capacity model predicts. Large gaps in either direction signal a model to fix:

• Capacity >> velocity — scope may be too ambitious, or estimates too small.
• Velocity >> capacity — capacity model may undercount availability, or the team is completing work not captured in planned load.

Three checks before you lock scope

Before the Product Owner and team agree on sprint scope in Jira sprint planning:

1. Capacity number for this sprint — from person-days, efficiency, and time off (capacity settings).
2. Velocity trend — average done SP over enough closed sprints to smooth noise (often three to six); check the sprint reports Done SP / sprint KPI or Jira’s velocity chart.
3. Last sprint forecast error — planned commitment vs. completed; carried-over load counts against this sprint’s budget.

If all three agree within a reasonable band, commitment is well grounded. If they diverge, resolve the gap before adding issues — not after the sprint starts.

For the full planning workflow (estimates, carry-over, buffer), see how to plan a realistic Scrum sprint.

Frequently asked questions

What is the difference between capacity and velocity?

Capacity is a forward-looking estimate of how much work the team can realistically take into the next sprint based on availability. Velocity is a backward-looking measure of how much work the team completed in previous sprints. Good sprint planning uses both: capacity for the current sprint and velocity as a reality check.

Should sprint commitment equal average velocity?

No. Average velocity describes past delivery. Sprint commitment, or planned scope, should reflect this sprint’s actual capacity — available time adjusted for absences, efficiency, carry-over, and focus. Velocity is useful as a calibration check, but it should not be treated as the budget by itself.

Can sprint capacity be higher than recent velocity?

Yes. Capacity can be higher than recent velocity if the team has more available person-days than in recent sprints, or if recent velocity was reduced by one-off events such as leave, incidents, or interruptions. Before planning above trend, check that estimates, team composition, and work type are comparable.

How many sprints do you need for a useful velocity average?

Velocity becomes more useful as history grows. Many teams use three to six recent closed sprints as a practical range. Fewer sprints can work if throughput is stable, but sprints with major roster changes, process changes, or unusual disruptions should be excluded or annotated.

Does Jira velocity count unfinished issues?

No. Jira velocity is based on work completed by the end of the sprint. Only issues that reached Done, according to the board’s column mapping, count as completed. Unfinished issues are not counted as completed velocity. Work added after the sprint starts can affect completed totals, but it does not change the original sprint commitment.

Where do I see velocity in Jira?

In Jira Software Cloud, open Reports on your Scrum board and view the Velocity Chart. It shows completed story points per sprint and helps teams compare planned work with delivered work. In ScrumNav sprint reports, velocity appears as Done SP per sprint and as an average across recent sprints. Capacity estimate is shown separately as the forward-looking planning number for the next sprint.

Do in-progress issues affect velocity or capacity?

They do not add to velocity — only Done work counts. They do affect capacity and planned load: carry-over should use remaining story points (estimate × (1 − completion %)), not always the full estimate. That is why strong velocity can still leave little room for new scope.