A Scrum velocity chart shows how many story points a team completed in each sprint over time. In Jira, it is available under Reports on any Scrum board. It is used to calculate average velocity and set realistic sprint commitments. Jira’s native chart shows team-level totals only — it cannot be broken down by individual user or filtered by issue type.
Velocity is one of the most used — and most misused — metrics in Scrum. Used correctly, the velocity chart is the most practical input for sprint planning. Used incorrectly, it becomes a pressure tool that distorts estimation and erodes team trust.
This guide explains what the Scrum velocity chart actually shows, how to read and use it in Jira, how to calculate average velocity correctly, and where the native chart stops being sufficient.
Related: Jira Scrum Reports: Burndown Chart, Velocity Chart, Sprint Report and Agile Reports Explained — overview of all four native Scrum reports in Jira.
A Scrum velocity chart is a bar chart showing how many story points — or other estimation units — a team completed in each sprint, displayed across a series of consecutive sprints. Each bar represents one sprint. The height of the bar represents the amount of work completed.
According to the Scrum.org definition, velocity is the amount of work a Scrum team completes during a single sprint, measured consistently using the same estimation unit across sprints. It is a team metric used for planning — not a performance measurement.
The velocity chart serves one primary purpose: giving the team a data-based foundation for deciding how much work to commit to in the next sprint.
Jira displays the last completed sprints automatically, typically showing the most recent 7 sprints. The chart is only available on Scrum boards in Jira Software projects. It is not available on Kanban boards or Jira Work Management projects.
Each bar in Jira’s Velocity Chart shows two values for the same sprint:
The gap between commitment and completed is the most informative part of the chart. Here is what different patterns mean:
| Pattern | What it means | What to do |
|---|---|---|
| Completed consistently below commitment | Team is regularly over-committing | Reduce next sprint commitment to match actual completed average |
| Completed consistently above commitment | Team is under-committing or pulling in unplanned work | Increase commitment slightly — review whether unplanned work is being tracked |
| Commitment and completed roughly equal | Healthy estimation accuracy | Use this sprint’s completed value to update rolling average |
| One sprint with unusually low completed | Outlier — holidays, incidents, or team changes | Exclude from average calculation or note the reason |
| Steadily increasing completed over time | Team is improving or growing | Recalculate average using only recent sprints to avoid underplanning |
Average velocity is the number you use as the basis for sprint planning. Here is how to calculate it correctly:
Example: if your team completed 34, 41, 38, 36, and 40 story points over five sprints, your average velocity is (34 + 41 + 38 + 36 + 40) ÷ 5 = 37.8 story points per sprint.
Use this number as the upper boundary for the next sprint’s commitment — not a target to exceed.
Most Scrum practitioners use 3 to 5 sprints. Using fewer than 3 makes the average sensitive to outliers. Using more than 7 may include data from when the team was larger, smaller, or using different estimation practices — making the average less representative of current capacity.
Exclude obvious outliers — sprints affected by public holidays, major incidents, or significant team changes — and note why they were excluded so the decision is visible to the whole team.
Velocity informs sprint planning in one specific way: it tells the team the realistic ceiling for how much to commit to. The process:
Velocity is historical — what the team actually completed. Capacity is forward-looking — what the team has available in the next sprint based on who is present and for how many days. Velocity informs capacity planning but they are not interchangeable. A sprint where two team members are on leave will have lower effective capacity than average velocity suggests, regardless of what the chart shows.
Jira’s native Velocity Chart has three significant limitations that matter as teams grow:
The chart shows team totals only. You cannot filter or break it down by assignee. This is by design — velocity is a team metric in Scrum, not an individual one.
That said, some teams legitimately need to understand workload distribution at the individual level for capacity planning purposes — not for performance evaluation, but to balance work and identify bottlenecks. For that use case, Report Hub provides a per-user velocity breakdown inside Jira Cloud.
You cannot separate bug velocity from feature velocity, or planned work from unplanned work. If your team consistently takes on a significant volume of unplanned bugs during sprints, the velocity chart averages that in without making it visible. Teams that want to understand this split typically use a custom dashboard gadget or a reporting add-on.
Jira’s native Velocity Chart only works for Scrum boards. Kanban boards have no sprints, so Jira does not calculate velocity for them. Teams using Kanban typically use throughput — issues completed per week — as the equivalent planning metric. For teams that want a Kanban velocity chart in Jira, this requires a reporting add-on such as Report Hub.
Jira allows you to add a Velocity Chart gadget to a dashboard so the team can monitor it alongside other sprint metrics without navigating to the Reports section separately.
How to add it: Go to Dashboards → your team dashboard → Add gadget → search for “Velocity Chart” → configure it to your board. The gadget updates automatically as sprints are completed.
For a full walkthrough on building a Scrum dashboard with multiple report gadgets in one view, see: How to Create a Custom Dashboard in Jira.
A Scrum velocity chart is a bar chart that shows how many story points a team completed in each sprint over a series of consecutive sprints. It is used to calculate average team velocity and set realistic commitments for future sprints. In Jira, it is available under Reports on any Scrum board.
Go to your Jira Software project → click Reports in the left sidebar → select Velocity Chart. It is only available on Scrum boards in Jira Software projects — not on Kanban boards or Jira Work Management projects.
Add up the story points completed across your last 3 to 5 sprints and divide by the number of sprints. For example: (34 + 41 + 38 + 36 + 40) ÷ 5 = 37.8 story points per sprint. Use completed story points — not commitment — and exclude outlier sprints affected by holidays or significant team changes.
Velocity is historical — how much the team actually completed in past sprints. Capacity is forward-looking — how much the team can take on in the next sprint based on current availability. Velocity informs capacity planning but a sprint where team members are on leave will have lower capacity than average velocity suggests.
No. Jira’s native Velocity Chart shows team-level totals only and cannot be filtered by individual user or assignee. To see velocity per person, you need a reporting add-on such as Report Hub.
No. Jira’s Velocity Chart is only available on Scrum boards. Kanban boards have no sprints so Jira does not calculate velocity for them natively. Teams typically use throughput — issues completed per week — as the Kanban equivalent. For a Kanban velocity chart inside Jira, a reporting add-on is required.
The Velocity Chart requires at least one completed sprint with estimated issues. Common causes: no sprints have been completed yet, issues were not estimated before the sprint started, or the board’s estimation statistic is set to a field with no values. Check Board → Configure → Estimation to verify the estimation field is set correctly.
Use the last 3 to 5 completed sprints. Fewer than 3 makes the average sensitive to outlier sprints. More than 7 may include data from periods when the team composition or estimation practices were different, making the average less representative of current capacity.
The Scrum velocity chart is a sprint planning tool, not a performance metric. Its job is to give the team a data-based answer to “how much should we commit to next sprint?” — based on what they have actually completed recently, not on what they hope to achieve.
In Jira, it lives under Reports on any Scrum board, updates automatically after each sprint, and requires no configuration beyond having estimated issues in completed sprints. Its main native limitation is that it shows team totals only — no breakdown by user, issue type, or project.
For the full picture of Scrum reports available in Jira, see: Jira Scrum Reports: Burndown Chart, Velocity Chart, Sprint Report and Agile Reports Explained.
For time tracking within sprint context alongside velocity data, see: Jira Time Tracking Reports: What’s Built In and What’s Missing.
Ready to Elevate Your Jira Setup?
Partner with Grandia Solutions to unlock expert configuration, reporting, and support services — tailored to your workflows. Whether you need custom dashboards, workflow automation, or long-term consulting, our team is here to make Jira work for you.