Velocity vs Throughput: Choosing the Right Delivery Metric for Your Jira Team

Velocity vs throughput is one of the most common metric comparisons for Jira teams. Both metrics describe delivery, but they answer different questions.

Velocity measures how much estimated work a team completes during a sprint. Throughput measures how many work items a team completes during a defined period. Velocity is usually the better fit for Scrum sprint planning. Throughput is often more useful for Kanban, service teams, and other continuous-flow systems.

Neither metric is a score for productivity. They do not tell you how much customer value was created, whether the work was high quality, or which person performed best. They are planning and flow signals. Used with the right context, they help your team make more realistic delivery decisions.

Velocity vs throughput: The short answer

Use velocity when you want to estimate how much work the same Scrum team can take into a future sprint. Use throughput when you want to understand how many work items a team or process completes per day, week, month, or another period.

Essentially, velocity shows how much estimated work a team completes in a sprint, while throughput shows how many work items it completes over a given period.

What is velocity in Agile?

Velocity is the amount of estimated work completed by a team during one sprint or iteration. Teams most often express it in story points. They can also use time estimates or another consistent estimation unit. Only work that meets the team’s agreed definition of Done should count as completed velocity.

Velocity is useful when the same team estimates in a stable way and works in consistent sprints. A recent range is often more helpful than one average. If the team completed 24, 30, and 27 points in its last three sprints, that history offers a realistic starting point for the next planning conversation, not a promise of exactly 27 points.

Velocity belongs to the team that produced it. One team’s five-point story may be very different from another team’s five-point story. Use the trend to improve one team’s planning, not to rank teams or set performance targets.

What is throughput in Agile and Kanban?

Throughput is the number of work items completed during a defined period. A Kanban team might track completed items per week, while a Scrum team can track completed items per sprint. Throughput does not require story points, and it is not limited to Kanban teams.

Throughput helps you see whether the delivery rate is stable, rising, or falling. It can also show whether completed work keeps pace with incoming demand. If 20 requests arrive each week but only 15 are completed, the backlog is likely to grow.

The metric has limits. Ten small requests are not equal to ten large features, and throughput does not show how long individual items waited. Pair it with cycle time, work in progress, and WIP age when you need to understand why the delivery rate changed.

Velocity vs throughput: the key differences

The clearest difference is the unit. Velocity measures estimated work, normally within sprints. Throughput counts completed work items during a period. This means each metric reacts differently when item size or estimation changes.

Velocity vs throughput: which one to choose for your Jira team

Start with the decision you need to make.

When you want to plan how much estimated work the same team can take into its next sprint, use velocity.

Use throughput when you want to know how many items a team or process completes during a consistent period. Use both when you need to separate changes in work-item count from changes in estimated size.

Do not use either metric to decide which team is more productive. Teams work with different products, risks, dependencies, workflows, and definitions of work. A comparison that ignores that context may be simple, but it will not be fair or useful.

How to track velocity with Jira native Velocity Chart

Jira provides a native Velocity Chart Report for Scrum projects. In a company-managed project, open the relevant project (space) or board, go to Reports, click the More Reports button, and select Velocity Chart.

The chart shows the team’s recent completed sprints. The commitment bar represents the estimated work in the sprint when it started. The completed bar represents the work completed when the sprint ended. An average line shows the average completed work across the sprints displayed.

Jira can base the chart on story points, original time, work item count, or a numeric custom field, depending on how you configure your board to estimate and track work. Although this flexibility is useful, being used in a scrum project, the estimation is usually in story points. A chart based on points and a chart based on item count answer different questions even if Jira calls both velocity charts.

When is Jira’s native Velocity Chart enough?

The native report is a good starting point for one Scrum team working from one board. It works well when the team uses standard sprint configuration and keeps estimates on parent work items. It is also enough when the report is opened only during planning or retrospectives and does not need to sit on a shared dashboard.

What are the native Velocity Chart Report limitations?

Jira’s native Velocity Chart is board-specific. Estimates from sub tasks are not included, it shows completed sprints only, so it does not include the current sprint, and you cannot filter them by sprint name or completion date.

The native chart shows one overall average across displayed sprints. It does not calculate a rolling average that changes from sprint to sprint. Jira also relies on the board’s column mapping to decide what counts as Done. The report counts a work item as completed only when its status maps to the last, far-right column of the board.

Finally, the chart is available as a report rather than as a standard native velocity dashboard gadget.

These limits matter when the team needs a persistent dashboard view, wants a custom Done definition or estimates sub tasks, or needs more control over sprint selection and averaging.

How to track throughput using native Jira features

Jira does not provide the same dedicated throughput chart report that it provides for velocity. For a Scrum team, Jira’s native Velocity Chart can also provide a throughput view. Configure the board’s estimation statistic as Work Item Count, then read the completed bar as the number of items finished in each sprint. That is throughput per sprint, even though Jira still calls the report a Velocity Chart. The Scrum-only scope does not change the metric; it only limits the chart to sprint-based intervals and one board.

You can also get a sense of the throughput trend from the Cumulative Flow Diagram Report. Open the relevant project (space), go to Reports, click the More Reports button, and select Cumulative Flow Diagram.

The slope of the Done area reflects completed work over time, while widening bands can point to growing WIP or bottlenecks. The report adds flow context, but it does not show a clean per-period completed-item count as directly as a dedicated throughput chart.

A clearer way to track velocity and throughput on Jira dashboards

Native Jira reports are useful when one team needs a standard board-level view. Reporting becomes harder when the metric needs to stay visible on a dashboard, include sub tasks, use a more specific definition of Done, or draw from a broader work scope. This is where Great Gadgets for Jira offers more flexibility.

Track velocity with the Team Velocity gadget

The Team Velocity gadget offered by Great Gadgets, displays the average velocity of a Scrum team together with its sprint history. You can use it to compare committed and completed work across sprints without leaving the Jira dashboard.

The gadget supports common estimation methods and lets you control which sprints appear. You choose how many previous sprints the chart displays, so the view is not limited to five. The gadget can also include the current active sprint.

You can filter the displayed sprints by text in the sprint name or by a completion-date range. You also choose how many recent sprints the gadget uses for its rolling-average calculation. This lets the chart show both a longer sprint history and a rolling average based on the window that best reflects the team’s current delivery pattern.

A particularly useful difference is sub-task support. You can exclude sub tasks, include them with their parents, or process only sub tasks. You can also choose custom Done statuses instead of relying only on the last board column. This helps teams whose estimation and workflow practices do not match Jira’s native parent-only, far-right-column calculation.

The gadget can display more than basic commitment and completion. Optional metrics include scope change, scope change absolute, work added, work removed, % scope change, % added, % removed, and % completed. A detailed data view also lets you inspect the work items and sprint statistics behind the chart.

Learn more: Team Velocity Gadget documentation

Track Kanban throughput with the Kanban Velocity/Throughput gadget

The Kanban Velocity/Throughput gadget offered by Great Gadgets, calculates delivery across past time intervals. For standard throughput, configure it to calculate by Work Item Count. The chart then shows the completed item count for each interval and the current average. This gives Kanban and service teams a direct view of their delivery rate.

But what if you want to calculate throughput based on story points?

This is a valid way to measure delivery volume when work items differ greatly in complexity or size. The gadget can also calculate by story points, original time estimate, or another numeric field.

Instead of counting every item equally, you can sum the story points completed during each interval. The same approach can use Original Time Estimate or a numeric custom field that represents effort, size, or another meaningful unit.

Keep the label clear. In flow terminology, throughput usually means the number of completed work items. A chart based on story points is more precisely described as story points completed per interval or estimated delivery volume.

The Kanban Velocity/Throughput gadget supports both views, so you can track item-count throughput and story points delivery volume side by side. It can also include sub tasks when they are part of the team’s real work model.

Learn more: Kanban Velocity/Throughput Gadget documentation

Put delivery rate in context

Velocity and throughput tell you how much work was completed. They do not explain everything that shaped the result. Add WIP Run and WIP Aging charts to see whether work is building up or getting stuck. Add Cycle Time Trend and a CFD charts to see whether delivery is slowing and where bottlenecks may be forming. These gadgets can be found in Jira Marketplace apps such as Great Gadgets.

A Time in Status gadget adds another layer of detail. It shows how long work items spend in each workflow status, status category, or board column. This helps you identify the specific workflow steps where work waits longest and where delays may be affecting throughput.

This combination is more useful than chasing one perfect metric. Velocity can support sprint planning. Throughput can show flow rate. WIP, cycle time and Time in Status can help explain why either one changed.

Velocity vs Throughput: Three examples of choosing the right metric

Final thoughts

Velocity and throughput are not competing versions of the same metric. Velocity helps a Scrum team plan estimated work across sprints. Throughput shows how many items a team or process completes during a consistent period. If Jira’s Velocity Chart is configured to use Work Item Count, its completed series is best understood as sprint throughput.

Start with Jira’s native reports when one team needs a straightforward board-level view. Move to a more configurable dashboard when you need flexible data sources, sub-task handling, custom Done rules, or several related metrics in one place. In either case, use the trend to ask better questions, not to create a performance scoreboard.

Want to bring velocity, throughput, WIP, cycle time, and other delivery metrics into one Jira dashboard?
Try Great Gadgets free for 30 days and build reports around the way your teams actually work.

Great Gadgets is an all-in-one reporting and dashboarding suite for tracking projects of any kind (Scrum, Kanban, SAFe, ITSM), with real-time dashboard gadgets that offer insights into progress, flow, delivery, forecasts and more.

• Great Gadgets for Jira Cloud
• Great Gadgets for Jira Data Center
• Great Gadgets for Confluence

FAQs:

Is throughput the same as velocity?

No. Velocity measures estimated work completed during an iteration, while throughput normally counts completed work items during a period. They may move in the same direction, but they use different units and answer different questions.

Can a Scrum team use throughput?

Yes. A Scrum team can track the number of items completed per sprint or per week alongside story-point velocity. This can make changes in the velocity chart easier to understand. If velocity rises while throughput stays flat, the team may be completing larger items or estimating differently.

Can a Kanban team use velocity?

A Kanban team can track story points or another estimate completed per period. However, throughput is normally the clearer flow metric because Kanban does not depend on fixed sprints. If you show points per month, describe the chart as delivered story points or estimated delivery volume. Clear labels matter more than the name of the gadget.

Is Jira issue-count velocity actually throughput?

Jira’s native Velocity Chart Report can use work item count as its estimation statistic. If you count completed items in each sprint, the result is conceptually throughput measured in sprint-sized intervals. Jira may display it in a report called Velocity Chart, but the unit is still completed items. The meaning comes from what you calculate, not only from the chart title.

Does Jira have a native throughput report?

Jira provides data that can help you calculate or understand throughput, including completed-work filters, Created vs Resolved, and the Cumulative Flow Diagram. However, it does not provide the same dedicated per-period throughput chart that it provides for native velocity reporting. The Kanban Velocity/Throughput gadget from Great Gadgets makes it easier to calculate and track completed work items (throughput) across consistent periods.

Can Jira’s native Velocity Chart include subtasks?

Atlassian’s current documentation states that estimates from sub tasks are not included in the native Velocity Chart Report. The Team Velocity gadget offered by Great Gadgets can include sub tasks, exclude them, or calculate only the sub tasks, depending on how the team estimates its work.

What other metrics should be tracked with velocity and throughput?

Add WIP and WIP age charts to understand current flow risk. Add cycle time and lead time to understand how long delivery takes. Sprint progress, scope change, defects, and customer outcomes provide more context about whether the work is both predictable and valuable.