Jira Metrics for Agile Teams: A 2026 Guide to Dashboard Setup and Flow Analysis

You might already check burndown charts in Jira before sprint planning. But if the same issues keep carrying over, you need to see why. Did your team take on too much, or did those issues spend several days waiting for review?

Jira holds the data to answer that question, as long as you pick the right metrics and read them together. In this guide, we'll cover:

• Which Jira performance metrics are worth tracking, and what each one can and can't tell you.
• Which built-in Jira reports answer which delivery question.
• How to build a Jira metrics dashboard step by step.
• How flow metrics in Jira show where work waits.
• How AI coding tools change what your Jira metrics show.
• How Jira reporting compares with tools like Jellyfish and Axify.

Let's get started!

What Are Jira Metrics?

Jira metrics measure how much work your team completes, how long issues take to finish, and where work builds up in your workflow. They're calculated from issue data, including sprint progress, completed issue counts, and the time issues spend in each workflow stage.

These metrics help you understand how work moves through your team's workflow. For example, measuring cycle time shows how much time passes between starting work on an issue and completing it.

Or if your team completed fewer issues over the last two sprints, you can check whether those issues spent longer waiting for review. That gives you a specific problem to discuss in your sprint retrospective and a possible change to try, such as assigning reviewers earlier.

Of course, issue counts alone can misrepresent team performance because tasks differ in size and difficulty. Use them alongside time-related metrics and issue details before deciding what needs attention. Jira metrics are one input into your broader software development KPIs, not a full picture of delivery on their own.

Check out this video if you want to learn more:

Which Jira Performance Metrics Should You Track?

The most useful Jira performance metrics are throughput, cycle time, work in progress, time in status, sprint commitment, and defect resolution time, read together rather than one at a time. Each one answers a different question about how your team delivers, and each one can mislead you on its own.

Use these metrics to understand how the team's system of work performs, not to rank individual developers. If cycle time rises while throughput stays flat, the problem is usually a stage where work waits, not a person who works slowly.

Pro tip: Jira metrics cover the planning and tracking side of delivery. For code review and deployment measures that Jira doesn't capture, see our guide to the top software engineering metrics to track.

What Are Jira Reports, and How Do You Choose the Right One?

Jira reports are built-in analyses of work-item data. They present metrics such as remaining sprint work, completed estimates, and time spent in workflow stages. The report you choose determines which delivery question you can investigate.

How to Open and Configure a Jira Report

1. Open the relevant Jira space. In a company-managed space with multiple boards, select the board whose work you want to analyze.
2. Select Reports. In the current Jira Cloud navigation, this opens the space insights dashboard. Select More reports to open the classic report catalog.
3. Choose a report for your question. Availability depends on your space type and configuration.
4. Set the available controls. Depending on the report, these may include a sprint, epic, version, date range, or workflow columns.

Check the scope before interpreting the result. A Control Chart measures elapsed time across the columns you select. Including a waiting stage changes what that measurement represents.

How Jira Reports Relate to Your Metrics Dashboard

Use reports to investigate a delivery question, then choose dashboard gadgets for the measures you need to monitor regularly. Some reports have corresponding gadgets; others, including the Control Chart and Cumulative Flow Diagram, are accessed separately.

How Do You Build a Jira Metrics Dashboard?

To build a Jira metrics dashboard, create a dashboard, add gadgets, and configure them to show your team's issues using saved filters. Start with the native options below, then add apps if you need more detailed workflow reporting.

Here are the steps you need to follow.

1. Create Your Dashboard and Save the Relevant Filters

Go to Dashboards → Create dashboard, name it, and set its sharing permissions. Save filters for the space, team, or sprint you want to review, and make sure viewers can access those filters too.

Keep the scope clear. For a sprint review, show that sprint's work. A list of every issue your team has ever completed makes current progress harder to assess.

2. Add Native Gadgets That Answer Specific Questions

Choose Agile dashboard metrics based on what you need to check. Select Edit → Add gadget, then configure each gadget's data source.

Useful starting options include:

• Filter Results to list issues needing attention.
• Created vs. Resolved to compare incoming and resolved issues over a selected period.
• Sprint Burndown to track remaining sprint work.
• Pie Chart to group issues by status or priority.

3. Review the Control Chart and CFD Together

Open Reports and, where shown, select More reports to access the Control Chart and Cumulative Flow Diagram. These charts are separate reports, not native dashboard gadgets. Confirm that you're viewing the intended board before comparing results.

Use the Control Chart to review completion times and the CFD to identify stages where work accumulates. Compare the same board and reporting period. If completion times rise while the review band widens, investigate issues waiting for review.

4. Add a Time in Status App for Detailed Waiting Times

If you need to see how long individual issues spend in "Code Review" or "Testing," consider a Time in Status app with dashboard gadgets. Check whether its calculations use calendar time or working hours before comparing results with other reports.

5. Identify Where Jira-Only Reporting Needs More Context

Built-in gadgets can't combine multiple data sources into one chart. Connecting issue progress with repository, build, and deployment data therefore requires additional reporting tools.

Team benchmarks and explanations of changing trends also need context beyond issue counts and status charts.

That brings us to Axify's Value Stream Mapping and its view of the steps between development and deployment.

Axify Alternative: Value Stream Mapping (VSM)

Jira's reports help you focus on sprint tracking, but what if you need a bigger picture? Axify's Value Stream Mapping combines work-item, pull-request, and deployment data from Jira, GitHub, GitLab, Azure DevOps, or Bitbucket to show delivery stages from planning to production, including how long work spends in each stage.

Instead of just tracking tasks, you get a clear view of where time is spent and where delays slow your team down. Axify's VSM allows you to:

• Track every step of the process from start to finish, not just within a sprint.
• Identify bottlenecks by pinpointing where work is piling up.
• Use trend indicators to add real-time insights into your workflow.
• Quickly navigate with information bubbles that provide helpful context.
• Sort work items by time spent in each phase to spot inefficiencies.
• Jump directly to the source software with one click to take action.
• Adjust the period observed to analyze short-term and long-term trends.

Teams that inspect these stages continuously see measurable results. Using DORA metrics and Value Stream Mapping, the Business Development Bank of Canada reached up to 51% faster delivery time over three months, with up to 81% less time spent in quality control.

Note: Axify Intelligence adds recommendations to the value stream analysis. Use them to select a workflow change to test, then review the affected stage's waiting time and overall delivery time to see whether the change helped.

What Are Flow Metrics in Jira?

Flow metrics in Jira describe how much work your team completes, what types of work it delivers, and how long items spend moving through the workflow. Atlassian's flow metrics dashboard template includes six metrics:

Review these measures together. If cycle time and WIP rise while throughput falls, inspect the stages where unfinished work is accumulating. Check work profile too: a shift toward different work types may affect the comparison.

The template is available in Insights (formerly Atlassian Analytics), which Atlassian includes in its Standard, Premium, and Enterprise plans. Some data sources, such as the Atlassian Data Lake, are limited to Enterprise, so check what your plan connects before you rely on it.

Warning: Configure active and waiting statuses carefully. Counting "Waiting for Review" as active inflates flow efficiency and hides the delay. For a closer look at how too much WIP drags this number down, read our guide on work in progress and flow efficiency.

Jira Metrics for AI-Assisted Teams

AI coding tools change how work moves through Jira before they change the numbers you report. Jira Cloud now lets you track AI agent sessions linked to your work items, respond to agents that are blocked, and review finished work. That tells you what agents are doing on a given issue. It doesn't tell you whether AI use is shortening delivery across a team, or what it costs.

As AI adoption grows, watch three signals in your Jira data:

• Time in review and testing: If issues leave "In Progress" faster but wait longer in "Code Review," AI is shifting the bottleneck to reviewers rather than removing it.
• Throughput by work type: More small tasks completed can raise throughput without changing what the team delivers. Check work profile before you read a rise as a gain.
• Reopened issues and bugs: A growing share of bugs among completed issues is a reason to look at review standards for AI-assisted changes.

To answer whether AI helps, you need AI usage and cost data next to your delivery data. Jira doesn't hold either.

How Axify Connects AI Adoption, Cost, and Delivery

Axify connects AI tool usage with your team's delivery data and spending, so you can check what changes as adoption grows.

Here's what you can track with Axify AI Adoption and Impact:

• AI adoption: Track active users, usage frequency, suggestion acceptance rates, and interaction counts by team, plus an AI adoption score built on reflexive use, reliance, and trust. This shows whether people regularly use the tools you're paying for.
• Delivery impact: Compare cycle time, completed work, PR review time, and other engineering metrics across teams with different adoption levels, and over time as adoption grows. These comparisons show whether higher usage coincides with faster completion or longer review queues.
• Cost: Track AI spending by tool, model, team, and person, with a cost forecast, alongside delivery metrics. This helps you assess whether higher spending leads to better delivery outcomes.
• Tools and models: See AI cost and token usage by model and tool, for tools such as GitHub Copilot, Cursor, and Claude Code, in the context of each team's work.

When measuring AI impact, compare usage, delivery, and spending over the same month. If AI tool usage increases while review time grows, investigate the review delays before buying more licenses. Higher usage by itself doesn't establish that a tool helps your team finish work faster.

Pro tip: For AI cost optimization, review spending and delivery metrics over the same period. A lower cost per completed item could reflect smaller changes, so check review feedback and test results before concluding that a tool produces usable code more cheaply.

Defect Metrics in Jira

Jira bug records can help you track defect volume and resolution trends. Measures such as defect density, escape rate, and test coverage require additional code, release, or testing data. Here are the measures to consider and what each can tell you:

• Defect density: Divides recorded defects by a defined measure of software size, such as 1,000 lines of code. Compare equivalent components and reporting periods; the result also depends on how thoroughly defects are detected and recorded.
• Defect escape rate: Measures production defects as a percentage of all defects recorded for the same release. An increase gives you a reason to investigate test coverage, test environments, and release checks.
• Defect resolution time: Measures elapsed time from a defect being reported to its resolution. Compare defects of similar severity, and check reopened issues before interpreting shorter resolution times as an improvement.
• Number of defects: Breaks down defects by stage (during development, after release, and those found by customers or other teams).
• Customer support requests: A spike in reported issues could indicate deeper product quality problems.
• Automated test coverage: Measures the proportion of code exercised by automated tests, using a defined measure such as line or branch coverage. Coverage data comes from testing tools; a high percentage alone does not establish that the tests catch important failures.

Tracking these defect metrics helps you decide where to focus testing and process improvements. The goal is faster fixes, better prevention, and higher-quality software.

Axify Alternative: High-Level Bottlenecks & Trends

Use Axify's flow and DORA metrics to investigate delivery delays and release failures alongside your Jira defect records. Longer review times and a rising change failure rate indicate different problems: the first calls for a review of waiting work, while the second calls for examining failed deployments and the changes behind them.

Axify Intelligence, which we mentioned above, analyzes delivery patterns and provides contextual recommendations when metrics change. Use that context to choose what to investigate with the team, then check the relevant work items, pull requests, or deployments before making a process change.

Can I Report Quality Metrics in Jira?

Yes, you can report software quality metrics in Jira using native issue reports, custom fields, and integrations.

Before building the report, check that the underlying records support the comparison you want to make:

• Release or version: Associate defects with the relevant release so reports do not mix unrelated changes.
• Detection stage: Record whether a defect was found during internal testing or after release.
• Severity: Separate critical failures from minor defects when reviewing resolution trends.
• Resolution and reopening history: Check whether apparently resolved defects were reopened.
• Reporting period: Apply the same dates and filters when comparing incoming and resolved defects.

Keep backlog reporting separate from conclusions about software quality. Created vs. Resolved can show whether unresolved reports are accumulating, but a shrinking backlog does not establish by itself that releases contain fewer defects.

What Quality Data Is Missing From Jira's Native Issue Reports?

Native issue reports alone don't supply code coverage, test execution results, or deployment failure data. So, you need to connect testing apps and delivery tools to add that context before assessing release stability.

Axify Alternative: DORA Metrics

The Axify DORA metrics dashboard brings together deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. DORA's current model also includes a fifth metric, deployment rework rate.

• Deployment frequency: Tracks how often your team deploys changes to production. Review it alongside failure rates before treating more deployments as an improvement.
• Lead time for changes: Measures the elapsed time from a change's first code commit to its successful deployment in production.
• Change failure rate: Measures the percentage of deployments requiring immediate intervention, such as a rollback or hotfix.
• Failed deployment recovery time: Measures how long it takes to restore service after a deployment causes a failure.
• Deployment rework rate: Measures the share of deployments that are unplanned and happen because of an incident in production. This differs from code rewritten during development or review.

Review these DORA metrics for the same application and reporting period. For example, if deployment frequency rises this month while unplanned, incident-driven deployments also increase, more releases may reflect corrective work. Check the incident-linked deployments before deciding that your team is delivering planned changes faster.

Newforma used this kind of continuous inspection of DORA metrics to reduce lead time for changes by 63% and deliver 22X more often over five months.

How to Estimate Project Progress in Jira

To estimate project progress in Jira, compare completed work and remaining scope with the original plan. Use the flow metrics explained above to check whether the team's recent delivery pace still supports the target date.

Apart from these, you can also track:

• Sprint commitment: Divides the story points completed from the original sprint scope by the story points committed at sprint start, then multiplies by 100. Track the trend within the same team and review scope changes, dependencies, and carryover before interpreting missed commitments as a planning problem.
• Time in status: Measures how long an issue remains in a particular state, such as "Code Review."
• Capacity utilization: For hours-based resource planning, compares logged work hours with available team hours over the same sprint. Compare planned and logged hours separately, and keep story points separate from hours.
• Scope creep rate: Measures issues or points added after a sprint or epic starts, expressed as a percentage of its original scope.

Review these five questions:

• How much of the original scope is complete? Separate work completed from the original plan from work added later. Otherwise, a growing completion count can hide an equally fast-growing backlog.
• Has the scope changed? Review additions, removals, and reopened work since the sprint, epic, or release began. If the remaining scope keeps growing, revisit the plan with stakeholders.
• Does the remaining work fit the team's recent delivery pace? Compare it with throughput across several comparable periods. Account for differences in item size and work type before using that history to estimate completion. Teams using story points can make the same check against their own completed estimates.
• What could delay the next milestone? Inspect aging work, blocked dependencies, and items waiting for review or testing. Check whether the people needed to finish them are available.
• Does the target date need to change? When scope, delivery pace, or team availability changes materially, update the estimate and explain which condition changed.

Keep the reporting boundary consistent. An issue marked Done may still be awaiting deployment, so distinguish development completion from production delivery when reporting a release milestone.

Use the review to make a concrete decision: reduce scope, resolve a dependency, change the sequence of work, or revise the delivery date.

How to Review Project Progress With Axify

Use Axify to examine what changed behind a project update.

If less work finished than expected, compare throughput across recent periods and check whether the mix of work changed.

The issue distribution view shows the share of completed work by issue type, so you can check whether more of it went to bugs, maintenance, or other work outside the planned feature scope.

AI Adoption and Impact adds AI performance metrics, including usage frequency and acceptance rates. You can review these alongside cycle time and review time for the same team and month to check whether increased adoption coincides with faster completion or longer reviews.

Our VSM tool shows how long work spends in each delivery stage.

Next, bring the findings back to the remaining plan.

For example, if bug work increased, check which planned items were deferred and whether the next milestone still fits the team's available capacity. Confirm the affected items with the team before revising the estimate.

Axify Intelligence analyzes those patterns and recommends workflow changes you can make. This gives you a specific delay to investigate and an action to consider.

With Axify MCP, you can query that data from a compatible AI assistant. Ask how your team's review time changed between the last two sprints, for example. Queries use live data and follow your existing Axify permissions.

How to Get Metrics for Reporter in Jira?

To report on issues submitted by a particular person, filter Jira work items by the Reporter field and save the filter. Use Filter Results to inspect those items or Issue Statistics to group them by status or another available field.

For example, you can review:

• Issues reported: Count the issues submitted by that reporter during a defined period.
• Resolution status: Check how many of those reported issues are resolved or still open.
• Issue age: Identify unresolved reports that have been waiting longer than expected.

These insights can help engineering managers like yourself see how incoming work is distributed, track responsiveness, and spot issues with team collaboration. Use them to understand where requests come from, not to judge individuals.

Axify vs. Jellyfish for Jira Metrics

Jellyfish uses Jira ticket movements and fields to power its allocation and investment views, which show how engineering effort is distributed across projects and work categories. Its Life Cycle Explorer, launched in 2023, tracks issues through Jira workflows and groups the time into refinement, work, review, and deployment phases.

Axify connects Jira work items with pull requests and deployments through flow metrics, DORA dashboards, and Value Stream Mapping, where you can see how long work spends in each delivery stage. Its AI Adoption and Impact feature puts AI usage and cost next to cycle time and throughput at the team or project level, so the AI discussion stays tied to delivery.

Both support workflow analysis, so compare them using the same team and month. Check how each defines completion, calculates review time, and groups work before deciding which reports fit your delivery reviews. If you're weighing options, our list of Jellyfish alternatives covers more tools.

Conclusion: Use Jira Metrics to Find the Delay, Then Fix It

Jira already tracks enough to show you whether your team is finishing what it plans and where work waits. Start with a small dashboard built on saved filters, read throughput, cycle time, and WIP together, and use the Control Chart and Cumulative Flow Diagram to find the stage where issues pile up.

When you need to see the whole path from ticket to production, or check whether AI coding tools are actually speeding up delivery, Jira alone won't answer it. Axify connects Jira with your repositories, deployments, and AI tools, so you can see AI usage, impact, and cost next to the delivery metrics you already track.

Try it on your own Jira data. Get started with a free 14-day trial, no credit card required.

FAQs

What are metrics in Jira?

Metrics in Jira are measurements calculated from work-item data, such as completed issue counts, sprint progress, resolution times, and time spent in workflow stages. They help you investigate planning and delivery patterns, but issue counts or story points alone do not establish productivity.

How to measure performance in Jira?

Assess delivery performance in Jira using completed work, cycle time, WIP, and sprint trends. Compare consistent reporting periods and inspect the issues behind significant changes. Measuring commit-to-production lead time also requires connected version-control and deployment data; Jira issue reports do not provide the full calculation.

Does Jira have analytics?

Yes, Jira has analytics through built-in reports, dashboard gadgets, and space insights. Burndown charts, cumulative flow diagrams, and velocity reports show progress and workflow patterns. Available reports depend on your space configuration, and broader analysis may require Insights, integrations, or additional apps.

What's the difference between Jira's native metrics and flow metrics?

Jira's native metrics describe what its built-in reports measure, while flow metrics describe how work moves through a process. They overlap through throughput, cycle time, and WIP. Flow efficiency adds the proportion of elapsed time spent in active workflow stages.

Can I get DORA metrics directly from Jira?

No, Jira's native issue reports alone cannot calculate all five DORA metrics. You need commit, deployment, and incident data to measure production delivery. Jira integrations, Atlassian reporting products, or engineering analytics tools can supply that additional data and the required calculations. Our guide on how to implement DORA metrics walks through the setup.

How do I compare Jira reporting to tools like Jellyfish or Axify?

Compare Jira reporting with Jellyfish or Axify using the same team, reporting period, and metric definitions. Check connected data sources, workflow-stage detail, benchmark relevance, and reporting effort. Then test whether each tool answers your actual delivery question.

What's the best Jira dashboard for a non-technical stakeholder?

For most non-technical stakeholders, the best Jira dashboard shows completed work, remaining scope, blocked issues, and upcoming releases in plain language. Keep filters consistent and label the reporting period clearly. Our Agile dashboard setup guide explains how to organize these views.