Velocity Report in Jira: How to Read & Calculate Team Velocity

For teams that run sprints, velocity is one of the most important metrics for predicting future capacity. The Velocity Report in Jira shows how much work your team completed in each sprint. This helps you plan more realistically, make better forecasts, and provide stakeholders with data-backed estimates. 

In this guide, you’ll learn where to find the Velocity Report in Jira, how to calculate average velocity, and how to get more advanced insights.

What Is a Velocity Report in Jira?

A velocity report shows the relationship between what your team committed to at the start of a sprint and what it completed by the end — tracked across several recent sprints so you can see the trend.

“Velocity” is simply the amount of work a team finishes in a sprint. It’s not a productivity score, and it’s not comparable between teams; it’s a planning instrument for one team over time. The point of a velocity report jira teams rely on is to answer one question: how much can we realistically commit to the next sprint?

Velocity is always measured in one estimation unit, and Jira supports three:

• Story Points — a relative measure of effort, the most common choice for Scrum teams.
• Issue Count / Work Item Count — the number of items completed, useful when items are similarly sized.
• Original Time Estimate — time-based estimates, for teams that estimate in hours.

Whichever unit your board uses, every figure in the report — committed, completed, and average — is expressed in that same unit.

How to Find the Velocity Report in Native Jira

Jira ships with a built-in Velocity Chart for Scrum boards:

1. Open your Scrum board (sprints must be enabled).
2. Go to Reports – More reports.
3. Select Velocity Chart.

The chart plots two bars per sprint — Commitment (what was planned) against Completed (what was actually done) — plus a horizontal Average line showing your team’s average completed work across the displayed sprints. It’s a clean, quick read of whether your forecasts match reality, and the average line gives you a planning baseline at a glance. 

That said, the native report is deliberately minimal. ⚠️ It’s team-level only — there’s no per-person breakdown. It tells you how much was completed, but nothing about where the sprint got stuck, how the scope changed mid-sprint, or how the work was distributed. For many teams, that’s the whole story they need; for others, it’s the start of more questions the native chart can’t answer. 

How to Calculate Average Velocity in Jira

Average velocity smooths out the noise from any single sprint and gives you a baseline for planning. Knowing how to calculate average velocity in Jira is straightforward once you have your completed values.

The standard Jira average velocity calculation takes the completed work from your most recent sprints and divides it by the number of sprints: 

Average Velocity = (Completed Sprint 1 + Completed Sprint 2 + … + Completed Sprint 7) / 7

Worked example. Say your last seven sprints completed the following story points:

That ~30 becomes your planning anchor — not your single best sprint of 35. Look at Sprint 3: the team committed to 40 but completed only 30. Planning another 40 would set the team up to miss again; the trend says ~30 is the honest number to commit to.

How many sprints should you average? Seven is a sensible default — recent enough to reflect the current team and process, long enough to absorb one-off spikes from holidays, incidents, or scope changes. Fewer than three sprints isn’t enough signal; reaching back a year pulls in a team that may no longer exist.

The good news: native Jira does the arithmetic for you — the Velocity Chart’s black average line already shows this rolling average across the displayed sprints, so you rarely need a spreadsheet just to find it. The real limits are flexibility and context: the native chart fixes which sprints it averages, can’t go on a dashboard, and won’t tell you why a low-average stretch happened — that’s where an app earns its place.

Limitations of the Native Jira Velocity Report

The native chart is good at one thing and silent on the rest. Common gaps teams run into:

• No flow context. Velocity tells you the sprint under-delivered, but not that items sat three days in Code Review waiting on an approver. The why lives in time in status data, the velocity chart doesn’t carry.
• No individual contribution view. There’s no breakdown of who carried what — useful for spotting an overloaded teammate, even if it’s the wrong tool for judging people.
• No scope-change or workload breakdown. Mid-sprint additions and removals are invisible, so a “missed” sprint can look like an estimation failure when it was really a scope-creep problem.
• No flexibility or dashboard view. The chart averages a fixed set of recent sprints, lives only on its board, and can’t be placed on a dashboard or filtered without a third-party app.

If any of those gaps matter to your retrospectives, you need a report that pairs velocity with the surrounding context. Here’s how the native chart stacks up against a fuller sprint report:

The velocity bars themselves are the same. What changes is everything around them — and whether you can answer why a sprint went the way it did.

From Velocity Number to Sprint Story: Time in Status

Here’s the honest part: the velocity chart in Time in Status for Jira isn’t a “better” velocity chart — it shows the same committed-vs-completed bars and average you already get natively. The difference is that it’s one section of a Sprint Performance Report that surrounds that number with the context native Jira drops, and connects it to the flow data that explains it. It works on any board with sprints enabled and automatically uses your board’s estimation method.

Team Velocity. The report charts Committed vs Completed across the last seven completed sprints, including the one you’ve selected (shown as the rightmost bar). Like native Jira, it supports Story Points, Work Item Count, and Original Time Estimate — parity here is the point; the value is what comes next.

What the native chart doesn’t give you, but this report does, in the same place:

• Completion Rate — completed ÷ committed as a percentage, so you see forecast accuracy at a glance (it can exceed 100% when the team over-delivers).
• Scope Change — items added and removed after the sprint started, so a missed commitment is explained, not just flagged.
• Status Time — total time work items spent in workflow statuses during the sprint, connecting velocity to where the time actually went.
• Workload by Assignee — each person’s committed, added, and removed work, so you can see how the sprint was distributed (more on this below).

The strongest difference isn’t any single chart, though — it’s the drill-down. When the report flags a problem, you can jump straight into the rest of the Time in Status toolkit — Status Count, Transition Count, and cycle/lead time reports — to find exactly where the work stalled. Native velocity ends at the number; here, the number is the starting point.

That combination turns velocity from a lagging score into a conversation starter for your retrospective. Say velocity dropped from 34 to 22 points. Native Jira tells you only that the sprint underperformed. The Sprint Performance Report shows that 11 points were added mid-sprint, and work items spent an average of three days in Review. Suddenly, the problem isn’t estimation — it’s scope change and a review bottleneck, and now you know what to actually fix. 

Individual Velocity in Jira: What’s Possible (and What Isn’t)

This is one of the most-searched and most-misunderstood requests, so let’s be precise. A true individual velocity report in Jira doesn’t exist — neither in native Jira nor as a dedicated feature in most apps. Velocity is defined as a team metric, and Jira’s native Velocity Chart has no per-person dimension. If you’re hunting for a “jira individual velocity report,” the honest answer is that the concept is built for teams.

The closest practical alternative is Workload by Assignee, available in the Sprint Performance Report. For each team member, it shows:

• Committed — work assigned at sprint start.
• Added — work assigned mid-sprint.
• Removed — work taken away during the sprint.

Each person’s workload is calculated as ((Committed + Added − Removed) / Total Sprint Commitment) × 100, which gives you their share of the sprint. This answers the real questions behind the “individual velocity” search — who started overloaded, who absorbed mid-sprint scope — without pretending to be a per-person speedometer.

On the dashboard. Heads up if you searched for an “individual velocity report in Jira dashboard”: native Jira has no velocity dashboard gadget at all — the Velocity Chart only lives in the board’s Reports section, not as a gadget you can drop onto a dashboard. To add a velocity view to a dashboard, you’ll need a Marketplace app, and even then, it stays at the team level. When you need the per-member angle, use Workload by Assignee inside the sprint report rather than chasing an individual velocity gadget.

⚠️ One caution worth stating plainly. Measuring individuals on velocity backfires: it encourages point inflation, discourages collaboration, and burns people out. Use per-assignee data to balance load and spot bottlenecks in the process, not to rank teammates.

How to Read Velocity Trends

A single number means little; the shape of the trend means everything. Across recent sprints, watch for:

• Consistent velocity — planned and delivered line up sprint after sprint. You have a predictable team; trust the average for planning.
• Increasing velocity — the team is steadily clearing more than it commits, often a sign of improving efficiency or better estimation.
• Fluctuating velocity — swings up and down point to dependencies, shifting scope, or estimation problems. Bring it to the retrospective and dig into what’s varying.
• Decreasing velocity — a downward drift can signal overload, recurring blockers, or burnout. Pair it with time-in-status and scope-change data to find the cause.

Used this way, velocity feeds both sprint planning (how much to commit) and retrospectives (why the last sprint went the way it did).

Common Mistakes When Using Velocity

Velocity is as easy to misuse as it is to read. The most common traps:

• Comparing velocity across teams. Story points are calibrated within a single team — one team’s 8 is another’s 3. Ranking teams by velocity measures estimation styles, not output.
• Treating velocity as a productivity score. It’s a planning input, not a performance grade. The moment it’s used to judge people, estimates inflate, and the number stops meaning anything.
• Benchmarking on your best sprint. One 35-point sprint isn’t your capacity; the average is. Planning for your peak guarantees you’ll under-deliver against your own plan.
• Ignoring scope change. When work is added mid-sprint, a “missed” commitment can look like bad estimation when it was really scope creep. Always read velocity next to what changed during the sprint.
• Chasing higher velocity. Velocity going up isn’t automatically good — it can mean point inflation, skipped quality steps, or unsustainable pace. Stable, predictable velocity beats a rising line you can’t trust.

The through-line: velocity answers “how much can we realistically commit to?” — not “how hard is the team working?” Keep it a planning tool, and it stays honest.

Conclusion

The Velocity Report in Jira is a good basic report for comparing planned and completed work, including average velocity. However, relying on it alone is not the best approach, as other metrics—such as scope change and team workload—are also important. Looking at the whole picture, rather than a single number, helps you better understand the efficiency of your processes and make more informed planning decisions.

Want deeper sprint insights? Try Time in Status on the Atlassian Marketplace. 

FAQ

How is average velocity calculated in Jira? Add the completed work (story points, work items, or original time) from your recent sprints and divide by the number of sprints — commonly the last seven: (Completed S1 + … + S7) / 7. You don’t have to do this by hand: native Jira’s Velocity Chart already shows the average as a black line across the displayed sprints, and the Time in Status Sprint Performance Report shows Average Velocity alongside completion rate, scope change, and workload.

Does Jira have an individual velocity report? No. Velocity is a team metric, and neither native Jira nor the Time in Status app provides a true per-person velocity report. The closest view is Workload by Assignee, which shows each member’s committed, added, and removed work for a sprint.

Can I see velocity on a dashboard? Not with native Jira. The built-in Velocity Chart only appears in a Scrum board’s Reports section — Jira doesn’t offer it as a dashboard gadget. To display velocity on a dashboard, you need a Marketplace app, and it remains a team-level metric.

Story points or issue count for velocity? Use whatever your board is configured with. Story points suit teams that estimate relative effort; work item count works when items are similarly sized; original time fits teams estimating in hours. Keep the unit consistent — switching units breaks trend comparability.

How many sprints should I use to calculate average velocity? Around seven is the sweet spot — recent enough to reflect the current team and process, long enough to smooth out one-off spikes from holidays or incidents. Fewer than three is too little signal; stretching back a year averages in a team that may no longer exist.

Why does velocity fluctuate between sprints? Some variation is normal. Persistent swings usually trace back to inconsistent estimation, mid-sprint scope changes, external dependencies, or shifting team availability. If velocity bounces a lot, that’s a retrospective signal — pair it with scope-change and time-in-status data to find what’s actually moving.

Is higher velocity always better? No. Velocity isn’t a target to maximize — it’s a forecast to trust. A rising line can mean genuine improvement, but it can equally mean point inflation or cutting corners. Predictable velocity is more valuable for planning than a high but erratic one.