There are plenty of metrics available in Jira, but I’m curious about which ones Scrum Masters genuinely find useful. If you had to choose only 5 metrics to put on a Scrum Master dashboard, what would they be and why? Some examples I’ve come across are: * Burndown/burnup * Velocity * Cycle time * Lead time * WIP * Carryover * Scope changes * Blocked issues * Workload distribution * Bug ratio Which metrics on this list do you not recommend using, and which important ones are missing? I’m especially interested in metrics that help you make a decision or take action, rather than metrics that simply look good on a dashboard.

Work Item Age and Cycle Time have been covered well above, so two things I'd add from the measurement side: * Report cycle time as the median and the 85th percentile, not the average. One ticket forgotten in Review for six weeks drags an average for months. The median ignores it, and P85 gives you an honest "most items finish within X days" that you can actually say in sprint planning. * Make every metric traceable to the work items behind it. The fastest way to kill a metric in a retro is someone saying "that number's wrong" and nobody being able to show the transitions it came from. If you can click from "9.5 days" to the items and their status history, the conversation stays on the work instead of the chart. The one I'd drop from your list is velocity as a target: useful for capacity planning, harmful as a score. Disclosure: I build Dwel — Time in Status for Jira, which is built around those two ideas (percentiles and a per-issue audit trail). Everything above works with any tool, though.

Hey Akankshya, As a Scrum Master, the best dashboard metrics are actionable flow indicators that trigger immediate conversation or process adjustments during sprint planning and retrospectives. Vanity metrics look nice, but flow metrics reveal the truth. If I had to choose 5 actionable metrics for a Scrum Master dashboard, here are the ones I recommend and why: * Cycle Time (True Working Time): Measures the time spent from when work actually begins (In Progress) to completion (Done). Why: It reflects true team delivery speed. Spikes in cycle time signal task slicing issues, hidden complexity, or technical blockers. * Status Duration / Blocked Time: Measures time spent sitting in specific waiting or blocked statuses (e.g., In Review, Waiting for QA, Blocked). Why: It pinpoints exact workflow bottlenecks so you can clear friction before sprint commitments fail. * Sprint Carryover / Rollover Count: Tracks how many times issues jump across multiple sprints without being completed. Why: It highlights overcommitment, poor task estimation, or creeping requirements. * Workload Distribution (Assignee Duration): Measures how long work remains under the responsibility of specific team members or roles. Why: It exposes resource bottlenecks and helps rebalance capacity dynamically to prevent burnout. * Rework & Reopen Counts (Status/Transition Counts): Tracks how many times an issue loops backward to an earlier status (e.g., Testing back to In Progress). Why: Frequent churn indicates unclear requirements or quality control issues in execution. How to get these metrics in Jira Vanilla Jira reports operate on a relentless 24/7 clock and lack flexible flow metrics. If you are open to using a Marketplace app, you can build this exact dashboard using Timepiece - Time in Status for Jira: * Custom Business Calendars: Calculates Cycle Time and status durations using your team's actual working hours—excluding weekends, nights, and holidays—so your metrics reflect real effort. * Dedicated Report Types: Provides built-in report types for Status Duration, Assignee Duration (workload), Status Count (rework loops), and Any Field Duration/Count (to track Sprint rollovers). * Dashboard Gadgets & AI Assistant: You can pin live-updating gadgets directly to your Jira dashboard or ask the built-in AI Assistant to configure reports using plain English. You can find Timepiece - Time in Status for Jira on the Atlassian Marketplace. Full disclosure: I am on the team that makes Timepiece.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

I want to know as a scrum master which Jira metrics do you actually use to understand sprint health?

Akankshya_M _Amoeboids_

There are plenty of metrics available in Jira, but I’m curious about which ones Scrum Masters genuinely find useful.

If you had to choose only 5 metrics to put on a Scrum Master dashboard, what would they be and why?

Some examples I’ve come across are:

Burndown/burnup
Velocity
Cycle time
Lead time
WIP
Carryover
Scope changes
Blocked issues
Workload distribution
Bug ratio

Which metrics on this list do you not recommend using, and which important ones are missing?

I’m especially interested in metrics that help you make a decision or take action, rather than metrics that simply look good on a dashboard.

Accepted answers

All comments

Viswanathan Ramachandran

Hi @Akankshya_M _Amoeboids_

The 5 Metrics That Drive Action:

Work Item Age (Active WIP Aging): Shows how long active work is stuck right now.
- Action: Swarm on aging items in daily stand-ups before the sprint fails.
Flow Efficiency (Active Time vs. Waiting Time): Exposes handoffs, queues, and dependencies.
- Action: Fix system bottlenecks instead of telling devs to "code faster."
Blocked Time (Categorised by Root Cause): Quantifies systemic organisational drag.
- Action: Use hard data to negotiate dependency SLAs and clear external blockers.
Planned vs. Delivered Ratio: Measures team predictability, not raw output.
- Action: If <80%, reduce sprint loading or fix backlog refinement.
Escaped Defect Rate: Balances speed with quality.
- Action: A spike signals rushed testing; pause feature push to tackle tech debt.

Skip These (Vanity / Counterproductive):

Velocity: Easily gamed, causes story-point inflation, useless for cross-team comparisons.
Burndown: Shows that you're late, but never why.
Internal Bug Ratio: Penalises logging bugs, leading teams to hide technical debt.

Re: Work Item Age - Stop looking backward at completed Cycle Time and start fixing aging work today.

Work Item Age is simply the total elapsed time between when an active item started (moved to "In Progress") and today. Think of it as Cycle Time for work that isn't finished yet.
ex: If a story moved to "In Progress" on Monday and today is Thursday, its age is 4 days.

Eduardo Anflor - MindPro

Hi, @Akankshya_M _Amoeboids_

It really depends on the process your company follows and the reporting needs managers have. For example, the most common metrics customers request from us are related to progress and volume. Charts like Velocity, Epic/Sprint Progress, cycle time, and Throughput are used to deliver this information.

If you are open to a marketplace solution, I recommend Mindpro Insights. I work at Mindpro, and I believe the app can help with your use case.

It allows any user to easily create dashboards with 50+ gadgets you can choose from. The gadgets are interactive, which means that when you click on any chart segment, the entire dashboard adapts to your filter. You can also share these dashboards internally or with external users via the customer portal.

Some examples:

Lead/Cycle time, Throughput:

Screenshot 2025-05-02 at 10.15.33.png

Epic Progress and Story points gauge:

Screenshot 2025-05-22 at 11.36.47.png

Velocity, Sprint progress, and board filter:

Screenshot 2025-04-22 at 10.25.36.png

I hope that helps.

Regards,

Eduardo

Anastasiia Maliei SaaSJet

On your point about “metrics that actually help me decide something” — I’d add Sprint Performance as a useful example.

In our Sprint Performance Report from the Time in Status app by SaaSJet, we focus less on a single final score and more on the signals that help explain why a sprint went the way it did:

Committed vs. Completed — by Story Points, Work Item Count, or Original Time, depending on the board’s estimation method.
Completion rate — including cases where it goes above 100% because additional work was added and completed during the sprint.
Carryover / spillover — what wasn’t finished and moved to the next sprint.
Scope changes — what was added or removed mid-sprint, which can otherwise make velocity look misleading.
Workload by assignee — committed, added, and removed work can help reveal uneven workload or scope being redirected.
Status time, flagged items, and logged time — useful for finding the reasons behind the numbers: work stuck in review/testing, too much WIP, blocked items, etc.

For the top chart, you can switch between Burndown and Team Velocity. I find velocity particularly useful for calibrating future commitments, while burndown helps understand the pace during the sprint.

Another useful part is that the report works with active sprints, so you can use it during the sprint rather than only looking back after it’s finished.

TIS 130.png

Evie Z.

@Anastasiia Maliei SaaSJet

Thanks for your post!

We’ve removed the external links from your post, per our Community Rules of Engagement, external links that may be promotional aren’t allowed in forum posts.

Akankshya_M _Amoeboids_

Thank you for sharing such an insightful breakdown! 🙌

The distinction between Work Item Age and Cycle Time was especially helpful. Looking at what’s still aging instead of only analysing completed work makes the data much more actionable.

Really appreciate you sharing this, it gave me a new perspective on how teams can use metrics to identify problems early rather than just measure them afterward.

Akankshya_M _Amoeboids_

@Anastasiia Maliei SaaSJet Thank you for sharing such a detailed and informative perspective!

I really liked how you’ve connected Sprint Performance with the actual questions teams need to answer, not just another metric to track.

The point about scope changes, carryover, and workload is especially valuable because these factors can easily get lost when we look at velocity alone.

Furthermore, the ability to use the report during an active sprint makes the insights much more actionable. Really appreciate you taking the time to explain this!

Akankshya_M _Amoeboids_

@Eduardo Anflor - MindPro Thank you so much for sharing this! The content is really informative and useful.

I especially found the explanation around Velocity, Epic/Sprint Progress, Cycle Time, and Throughput helpful. The interactive dashboards and the ability to filter the entire dashboard based on a chart segment sound particularly useful for analysing data from different perspectives.

Really appreciate you taking the time to share these insights and examples! 👏

Elita Kalāne - eazyBI Support

Hello @Akankshya_M _Amoeboids_

Disclosure (I work for eazyBI) so my comment here comes from the reporting side, but here's what we consistently see Scrum Masters keep using.

- Velocity as a trend, not a single number - a 3–5 sprint rolling average of committed vs. completed story points. One sprint's velocity tells you almost nothing; the trend tells you whether throughput is stable, improving, or slipping, and whether the current sprint plan is realistic.

- Commitment completion % (say/do ratio) - how much of what was committed at sprint start actually got done, tracked sprint over sprint. This is really a predictability metric: a team at 60% one sprint and 95% the next has a planning problem, not a "the team is slow" problem.

- Scope change / stability - points added vs. removed vs. changed mid-sprint. This is one of the more actionable ones, since it usually points straight at a process issue (weak refinement, stakeholder pressure, unclear acceptance criteria) rather than a team performance issue.

- In-sprint burndown against a guideline - less useful as a historical chart, more useful live: is the team on track to finish, and is that visible early enough to act on (descope, get help, flag risk) rather than on the last day.

- A rather interesting use case I ran into recently - calculating how many sprints it would take to burn down all the outstanding (remaining) estimated hours for a certain project and considering the last 5 sprint velocity for logged hours.

I'd second @Viswanathan Ramachandran point above on Work Item Age / blocked time over plain velocity or burndown - aging work items catch problems like stuck reviews or blocked dependencies days before they'd show up in a burndown.
Things I'd be cautious with: a single burndown chart in isolation (it shows that you're behind but not why), and raw velocity compared across teams (story points aren't calibrated between teams, so it invites the wrong conversation).

Here is just an example of how some of our sample dashboards look that we have found to be useful among eazyBI users.

Thank you for a useful discussion!

Best,

Elita from support@eazybi.com

Akankshya_M _Amoeboids_

@Elita Kalāne - eazyBI Support The point about velocity being a trend, not a single number, really stood out. It’s easy to look at one sprint and draw conclusions, but the bigger picture tells a much more useful story.

I also liked your take on scope change and work item age. These metrics help teams understand why a sprint is slipping, rather than simply showing that it is.

From a marketing perspective, this is a great reminder that the best dashboards are not just about displaying data. They help teams ask better questions, spot risks earlier, and have more meaningful conversations.

And the example of calculating how many sprints it might take to clear outstanding work is a really interesting use case.

Thanks for sharing these insights and the dashboard examples! 👏

Birkan Yildiz _OBSS_

Hey Akankshya,

As a Scrum Master, the best dashboard metrics are actionable flow indicators that trigger immediate conversation or process adjustments during sprint planning and retrospectives. Vanity metrics look nice, but flow metrics reveal the truth.

If I had to choose 5 actionable metrics for a Scrum Master dashboard, here are the ones I recommend and why:

Cycle Time (True Working Time): Measures the time spent from when work actually begins (In Progress) to completion (Done). Why: It reflects true team delivery speed. Spikes in cycle time signal task slicing issues, hidden complexity, or technical blockers.
Status Duration / Blocked Time: Measures time spent sitting in specific waiting or blocked statuses (e.g., In Review, Waiting for QA, Blocked). Why: It pinpoints exact workflow bottlenecks so you can clear friction before sprint commitments fail.
Sprint Carryover / Rollover Count: Tracks how many times issues jump across multiple sprints without being completed. Why: It highlights overcommitment, poor task estimation, or creeping requirements.
Workload Distribution (Assignee Duration): Measures how long work remains under the responsibility of specific team members or roles. Why: It exposes resource bottlenecks and helps rebalance capacity dynamically to prevent burnout.
Rework & Reopen Counts (Status/Transition Counts): Tracks how many times an issue loops backward to an earlier status (e.g., Testing back to In Progress). Why: Frequent churn indicates unclear requirements or quality control issues in execution.

How to get these metrics in Jira

Vanilla Jira reports operate on a relentless 24/7 clock and lack flexible flow metrics. If you are open to using a Marketplace app, you can build this exact dashboard using Timepiece - Time in Status for Jira:

Custom Business Calendars: Calculates Cycle Time and status durations using your team's actual working hours—excluding weekends, nights, and holidays—so your metrics reflect real effort.
Dedicated Report Types: Provides built-in report types for Status Duration, Assignee Duration (workload), Status Count (rework loops), and Any Field Duration/Count (to track Sprint rollovers).
Dashboard Gadgets & AI Assistant: You can pin live-updating gadgets directly to your Jira dashboard or ask the built-in AI Assistant to configure reports using plain English.

You can find Timepiece - Time in Status for Jira on the Atlassian Marketplace.

Full disclosure: I am on the team that makes Timepiece.

Better Integrations

Work Item Age and Cycle Time have been covered well above, so two things I'd add from the measurement side:

Report cycle time as the median and the 85th percentile, not the average. One ticket forgotten in Review for six weeks drags an average for months. The median ignores it, and P85 gives you an honest "most items finish within X days" that you can actually say in sprint planning.
Make every metric traceable to the work items behind it. The fastest way to kill a metric in a retro is someone saying "that number's wrong" and nobody being able to show the transitions it came from. If you can click from "9.5 days" to the items and their status history, the conversation stays on the work instead of the chart.

The one I'd drop from your list is velocity as a target: useful for capacity planning, harmful as a score.

Disclosure: I build Dwel — Time in Status for Jira, which is built around those two ideas (percentiles and a per-issue audit trail). Everything above works with any tool, though.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud