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

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

Hi @Akankshya_M _Amoeboids_ 

The 5 Metrics That Drive Action:

1. 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.

2. Flow Efficiency (Active Time vs. Waiting Time): Exposes handoffs, queues, and dependencies.

   • Action: Fix system bottlenecks instead of telling devs to "code faster."

3. Blocked Time (Categorised by Root Cause): Quantifies systemic organisational drag.

   • Action: Use hard data to negotiate dependency SLAs and clear external blockers.

4. Planned vs. Delivered Ratio: Measures team predictability, not raw output.

   • Action: If <80%, reduce sprint loading or fix backlog refinement.

5. 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.

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.

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:

Epic Progress and Story points gauge:

Velocity, Sprint progress, and board filter:

I hope that helps.

Regards,

Eduardo