How to Create a Velocity Chart in Jira

Most teams treat sprint planning like a guessing game. They commit to a number, hope for the best, and wonder why delivery keeps slipping. The velocity chart in Jira is designed to end that cycle — but only if you know how to use it right.

This guide walks you through exactly how to create, read, and act on a velocity chart in Jira. Whether you’re running your first sprint or trying to bring more predictability to an existing team, this will give you the framework to plan with real data instead of optimism.

What Is a Velocity Chart in Jira?

A velocity chart is a visual report that shows how much work your team committed to versus how much it actually completed — across multiple sprints.

In Jira, it displays two bars for each sprint:

• Commitment (gray bar): The total story points planned at the start of the sprint
• Completed (green bar): The actual story points finished by the end of the sprint

A horizontal average line runs across both bars, showing your team’s rolling average velocity across all displayed sprints.

The gap — or alignment — between those two bars tells you more about your team’s health than any standup ever will.

Velocity in Jira is calculated by averaging the total completed story points across the most recent sprints. For example, if a team completed 17.5, 13.5, 38.5, 18, 33, and 28 story points across six sprints, their velocity is (17.5 + 13.5 + 38.5 + 18 + 33 + 28) / 6 = 24.75 story points per sprint.

That number becomes your planning baseline. The more sprints you run, the more reliable it gets.

Why Velocity Charts Matter More Than You Think

Here’s the uncomfortable truth: 27% of teams say a lack of defined metrics is actively holding back their agile transformations. Most of those teams are flying blind in sprint planning — making commitments based on gut feelings instead of historical data.

The velocity chart fixes that. Here’s what it unlocks:

Predictable delivery. When you know your team’s average velocity, you stop overpromising. You can tell stakeholders with confidence how much will ship and when.

Early warning signals. A velocity that swings wildly from sprint to sprint isn’t random — it’s a symptom. Scope creep, estimation drift, unplanned work, team churn. The chart surfaces these patterns before they become crises.

Better retrospectives. Teams that conduct effective retrospectives have 20% higher balanced performance than those that skip them. Velocity data gives retrospectives something concrete to discuss — not just feelings, but facts.

Sustainable pace. Sprint completion rates often sit between 60–70% for teams that habitually overcommit. The velocity chart shows you where your true ceiling is, so you stop burning people out trying to hit unrealistic targets.

And the Scrum adoption numbers back this up: 81% of agile teams use some version of Scrum, and 86% of Scrum teams hold sprint planning meetings. The velocity chart is the one artifact that makes those planning meetings data-driven instead of speculative.

What You Need Before Creating a Velocity Chart

Before you access the chart, make sure three things are in place:

A Scrum board, not a Kanban board. The velocity chart is exclusive to Scrum boards in Jira. If your team is using a Kanban setup, you won’t see this report. You need to be working in a company-managed or team-managed space with the Scrum template enabled.

At least one completed sprint. The chart requires historical data. You need at least one finished sprint before any data appears. The more sprints you have, the more accurate the velocity average becomes — most teams rely on a minimum of three to six sprints for meaningful planning input.

Story points or another estimation unit enabled. If your team hasn’t enabled the estimation feature, Jira will default to counting work items with equal weighting. Story points give you far more nuance, especially when task complexity varies. Note that sub-task estimates are not included — only parent task estimates count toward velocity.

Sprints with no mid-sprint additions to the initial commitment. Any work items added after a sprint begins are included in the completed total but not in the commitment bar. This is by design — it captures scope changes transparently.

How to Access the Velocity Chart in Jira

Accessing the velocity chart takes less than a minute once your board is set up.

For Jira Cloud (Company-Managed):

Navigate to your Scrum board. In the left sidebar, click Reports. From the reports menu, select Velocity Chart. Jira will load the chart automatically, showing sprints from the past three months by default.

For Jira Data Center / Server:

Navigate to your desired Scrum board. Click Reports in the board menu, then select Velocity Chart from the list.

To customize what you see:

• Timeframe: Change the default view from “last 3 months” to a custom date range, or select from predefined timeframe options. Your selection is saved in the URL, so you can share the exact view with teammates.
• Viewing options: Use the “Viewing options” panel to hide unrelated sprints. This is especially useful if issues were moved between boards — those cross-board sprints can skew your velocity data. Enabling the filter ensures only sprints from your specific board are included.
• Focus: Use the focus feature to zoom into the sprint range you care about most.
• Save as image: Click the save option to export the chart for use in reports, retrospectives, or stakeholder presentations.

By default, Jira’s built-in velocity chart displays the last 7 sprints. This number is fixed in the native report and cannot be changed without a third-party app.

How to Read the Velocity Chart

Reading the chart is straightforward once you know what each element means.

The gray bar (Commitment): This represents the total story points in the sprint at the moment it began. Work added after kickoff does not change this bar — which is exactly the point. It locks in what the team agreed to.

The green bar (Completed): This captures everything actually finished by sprint end, including scope that was added mid-sprint. If the green bar consistently falls short of the gray bar, you have a planning problem. If it consistently exceeds the gray bar, your team may be under-committing.

The black average line: This is the most important number on the chart. It represents the rolling average of completed work across all displayed sprints. Velocity is calculated from this line. If a sprint had zero story points completed, Jira typically ignores it in the average calculation to prevent distortion.

What to look for:

• Bars of equal height: This is the ideal. Your team is committing to what it can actually complete.
• Consistent pattern: Velocity that stays within a predictable range indicates a healthy, stable team.
• Dramatic spikes or drops: These signal disruptions — new team members, scope explosions, unexpected blockers, or underestimation. Investigate before the next sprint.
• Persistent gap between gray and green: If committed always outpaces completed by a wide margin, your estimation process needs work. Teams that address this typically find their sprint completion rate climbs from that 60–70% range toward 85–95%.

Hover over any sprint bar in the chart to see detailed data — the exact commitment value, completed value, and any scope changes made during that sprint.

How to Use Velocity Data to Improve Sprint Planning

This is where the chart earns its value. Here’s how to put it to work.

Use the average as your planning ceiling, not your target. Pull the average velocity from the chart and use it as the maximum commitment for the next sprint. Don’t try to beat it — use it. Teams that consistently plan to their average rather than their aspirational high deliver more reliably over time.

Account for capacity before committing. Average velocity assumes full-team availability. If someone is on leave, a public holiday falls mid-sprint, or the team is smaller than usual, adjust downward proportionally. A common approach: calculate the sprint capacity as a percentage of full capacity, then multiply by average velocity. For example, a team at 80% capacity with an average velocity of 40 points should plan for roughly 32 points.

Calculate from the last three to six sprints. The general best practice is to average the last three to six sprints. Too few and you’re vulnerable to outliers. Too many and you dilute the signal from recent performance changes.

Let velocity inform release forecasting. Divide the remaining story points in your backlog by your average velocity to estimate how many sprints it will take to complete. This gives stakeholders a realistic timeline and reduces the pressure to inflate commitments.

Flag high variance as a risk, not just a metric. If your velocity range spans 15 to 60 story points across six sprints, that’s not a planning tool — that’s noise. Investigate the cause before relying on the average. Stabilizing velocity is often more valuable than increasing it.

Common Mistakes Teams Make with Velocity Charts

Knowing what to avoid is just as important as knowing what to do.

Comparing velocity across teams. Velocity is team-specific. A team averaging 80 points is not twice as productive as a team averaging 40. Story point scales differ, estimation styles differ, team composition differs. Using velocity as a cross-team comparison metric will damage morale and distort decision-making.

Treating velocity as a productivity score. Velocity tracks story point completion — not quality, not business value, not customer outcomes. A team that rushes through low-quality work to inflate its velocity is not winning. Pair velocity with code review metrics, bug rates, and customer feedback for a complete picture.

Ignoring scope changes. If your team regularly adds significant work mid-sprint, the completed bar will look inflated compared to the commitment bar. This makes planning harder, not easier. Track scope changes deliberately and discuss them in retrospectives.

Punishing low-velocity sprints. Teams that face pressure to hit or exceed average velocity start gaming the metric. Story points inflate. Estimates become padding. The chart loses its meaning. Protect velocity data from being used as a performance stick.

Relying on only one or two sprints. One sprint is an anecdote. Three sprints is a pattern. Six sprints starts to become a planning foundation. Don’t lock in your planning approach based on a single sprint result.

Limitations of Jira’s Built-In Velocity Chart

Jira’s native velocity chart is a strong starting point, but it has real constraints that teams at scale run into quickly.

It only shows the last 7 sprints. The number of sprints displayed in the built-in chart is fixed. You cannot change it without a third-party Jira app. For teams that want longer historical views or custom date ranges, this becomes a meaningful limitation.

It’s board-specific and can’t be added to the Jira Dashboard. The built-in velocity chart is tied to a single Scrum board. You can’t surface it as a gadget in your dashboard, which means you can’t monitor it alongside other key project metrics in one view.

It doesn’t expose advanced metrics. The native chart shows commitment and completed. It doesn’t surface rollover (incomplete work carried to the next sprint), scope changes broken down by type, estimation drift, or multi-team benchmarking. Research suggests most teams default to just these two basic metrics — not because they’re sufficient, but because that’s all the native tool offers.

Sub-task estimates are excluded. If your team uses sub-tasks with their own estimates, none of that data flows into the velocity calculation. Only parent task estimates count.

For teams that need more depth — multi-team views, breakdown by issue type, custom sprint counts, trend overlays — third-party apps on the Atlassian Marketplace fill these gaps. Options like Agile Reports & Gadgets and Agile Velocity Chart Gadget are popular choices that sit directly on the Jira Dashboard.