How to Create a Sprint Velocity Report in Jira (Step-by-Step)
The Jira Velocity Chart is the primary tool for understanding how much work your team completes per sprint. It shows committed vs. completed story points across the last several sprints, revealing whether the team is consistently overcommitting, trending toward higher or lower velocity, and how reliable sprint estimates have become over time.
This guide covers accessing, interpreting, and acting on the Jira Velocity Chart for better sprint planning.
Step-by-step guide
Access the Velocity Chart
In your Jira project, click "Reports" in the left sidebar. Select "Velocity Chart." The chart shows your last 7 completed sprints by default. Each sprint has two bars: a gray bar (committed story points at sprint start) and a green bar (completed story points at sprint end). The gap between the two bars is the overcommitment.
Read the velocity chart correctly
Average velocity is the mean of completed (green) bars across the sprints shown. Do not average the committed bars — teams consistently overcommit, which distorts the planning baseline. For planning, use: average velocity = sum of completed story points / number of sprints. Most teams should plan to 80% of this average to buffer for unplanned work.
Identify velocity trends
Look at the completed bars across time: Upward trend = team is improving (better estimation, reduced friction, ramping members). Downward trend = investigate (scope creep, technical debt accumulating, team changes). Flat line = stable, predictable velocity — ideal for reliable planning. High variance (spikes and troughs) = unpredictable sprint completion, usually caused by inconsistent estimation.
Analyze committed vs. completed gap
If committed consistently exceeds completed by 30%+, sprint planning is systematically overoptimistic. Calculate the planning ratio: completed/committed for each sprint. A healthy ratio is 0.85-1.0. A ratio consistently below 0.7 means the team is committing to 40%+ more than they can deliver — a planning accuracy problem requiring immediate attention.
Filter velocity by issue type
Jira's default velocity chart combines all issue types. For accurate analysis, create separate velocity reports for Stories vs. Bugs. If bug volume is high and variable, it introduces noise into the story velocity. Separate tracking reveals whether story completion is stable even when total velocity fluctuates due to emergency bug work.
Export velocity data for deeper analysis
Click the "Export CSV" button on the Velocity Chart to download the raw data. Import it into Google Sheets or Data Studio for: rolling 3-sprint velocity average (smoother than the 7-sprint view), velocity per engineer (useful for capacity adjustments during team changes), and correlation between sprint length and velocity.
Use velocity data in sprint planning
At the start of each sprint planning session: open the Velocity Chart, calculate the 3-sprint rolling average of completed points, adjust for this sprint's availability (divide by 10 business days × team size, multiply by actual available days), set this as the sprint's story point ceiling, and stop adding stories when the ceiling is reached.
Common mistakes
Planning to the committed bar, not the completed bar
The committed bar shows what the team hoped to accomplish. The completed bar shows what actually happened. Plan based on completed velocity — the realistic baseline — not the aspirational committed baseline.
Averaging velocity across teams
Velocity is team-specific. A team of 5 doing 40 points and a team of 3 doing 25 points cannot be averaged. Each team has its own velocity baseline calibrated to its members, estimation style, and workflow.
Not controlling for sprint length consistency
If some sprints are 2 weeks and others are 3 weeks due to holidays, the velocity chart will show artificial spikes and troughs. Control for sprint length by normalizing to story points per working day when comparing across inconsistent sprint lengths.
Tips
Screenshot the velocity chart at the start of every sprint planning session and include it in the sprint planning doc
Set a target completion ratio (e.g., 0.85) as a team health metric and discuss it in every retrospective
Use velocity trend data to project when large epics will complete based on current velocity — this is your evidence for stakeholder timeline conversations
Check the velocity chart after every sprint retro to see if retro action items are improving velocity over time
How Vantage helps
Vantage generates wave-based tickets that give sprint planning a structured starting point. The dependency-aware waves prevent the common velocity problem of engineers idling while waiting for blocked work — Wave 2 tickets are only started when Wave 1 completes, maintaining sprint throughput.