Short definition
Velocity in Jira is the average number of story points a Scrum team completes per sprint, calculated as a rolling average across the last several sprints (commonly three to five). Jira's Velocity Chart shows committed versus completed points sprint over sprint, and teams use the rolling average to forecast how much work to pull into the next sprint.
What velocity represents
Velocity is the single number that lets a Scrum team answer “how much can we commit to next sprint?” It’s the rolling average of story points completed across recent sprints - not a target, not a quota, just an observation about the team’s historical throughput. Jira’s Velocity Chart visualises this as a bar chart of committed (grey) versus completed (green) points per sprint, with the rolling average displayed alongside.
The metric exists because human estimates of effort are unreliable in absolute terms but reasonably stable in relative terms. A team can’t say “this story will take 6.4 hours,” but it can say “this story is about the same size as the one we sized 5 points last month.” Velocity converts that relative consistency into a planning number.
How Jira calculates it
Jira sums the story points of issues moved to a Done status category inside each closed sprint, then averages across the last N closed sprints (configurable, default rolling average). Only completed work counts. A 13-point story that’s 95% done at sprint end contributes zero points - it carries into the next sprint where, when finished, it counts there.
This is deliberate. The metric measures finished, releasable work, not effort spent. Teams that try to partial-credit unfinished stories quickly lose the predictive value of the number.
Common misuses
Three patterns destroy velocity as a planning tool:
- Treating it as a target. “Last sprint we did 32; this sprint we’ll do 35.” Velocity is an observation, not a goal. Pushing it up forces estimate inflation.
- Comparing across teams. Story points are per-team calibration. Team A’s 5 is not Team B’s 5. Comparing velocities ranks teams on their estimation scales, not their output.
- Counting unplanned work in the average. Sprints disrupted by incidents skew the rolling average downward. Most teams either point unplanned work as it lands (preferred) or note the disruption in the sprint retrospective so the dip is explained rather than absorbed.
Velocity and forecasting
Once a team has a stable rolling velocity, simple forecasting becomes possible: “we have 180 points of backlog at a velocity of 30 = roughly 6 sprints of work.” Jira’s Advanced Roadmaps / Plans tool automates this for epics and releases. The forecast tightens as velocity stabilises - new teams or teams in flux should expect wide error bars for several sprints before relying on the number.
For teams that estimate via a custom field other than the default story-point field, the Custom Fields product is the easiest way to audit which field is wired into the velocity report and confirm every active sprint issue carries a value.
See also (Redmoon products)
Common questions
What is velocity in Jira?
Velocity is the average number of story points a Scrum team completes per sprint, calculated as a rolling average across the last several sprints (commonly three to five). Jira's Velocity Chart shows committed versus completed points sprint over sprint, and teams use the rolling average to forecast how much work to pull into the next sprint.
How is velocity calculated in Jira?
Jira sums the story points of issues completed (moved to a Done status category) inside each closed sprint, then averages that figure across the last several sprints. Only completed issues count - work spilled to the next sprint contributes zero points to the current sprint's velocity, even if it was mostly finished.
Should teams compare velocity across teams?
No. Story points are calibrated per team, so one team's 30-point sprint is not comparable to another's. Comparing velocities across teams pressures them to inflate estimates, which destroys the metric's planning value. Velocity is a within-team forecasting tool, not a cross-team productivity measure.
Why did our velocity drop suddenly?
Common causes: a sprint with heavy unplanned work (incidents, urgent bug fixes that weren't pointed), team members on leave, a large story that spilled to the next sprint contributing zero points, or a recent re-calibration of what a point means. Look at the sprint report's scope changes and incomplete issues first.