How to Run a Jira Workflow Health Check Using Status Transition Data

[#1]

Most team leads know when something feels off. Like: 

• Tickets are taking forever.
• The same issues are showing up in every standup. 
• A sprint that closes cleanly on paper but felt like a grind. 

But the real problem isn't awareness; it's that Jira's default views don't tell you why things slowed down. They tell you what's open and what's closed. Everything in between is a black box.

Status transition data is what opens that box. It helps identify bottlenecks, inefficiencies, and potential issues that could impact your team's productivity. As a team lead, understanding how to run a Jira workflow health check using this data can lead to substantial improvements in your team's overall performance.

Here's how to actually use it.

1. Start with Your Workflow Map, Not Your Dashboard

Before you look at any data, get clear on what your workflow is supposed to look like. 

Open your Jira workflow configuration and document every status your issues pass through: Backlog, In Progress, In Review, UAT, Done, whatever your team uses.

Then look at the transitions: 

• Which statuses connect to which? 
• What are the valid paths an issue can take?

This matters because the moment you start looking at transition data, you need a baseline. You need to know what "normal" looks like before you can spot what isn't. If you don't have a clear picture of your intended workflow, you'll spend time analyzing noise instead of signal.

2. Jira Time in Status: The Metric That Tells You Where Work Dies

Here's the thing about bottlenecks: They're almost never where you think they are. 

Teams assume the slowdown is in development. The data usually points somewhere else: code review, QA hand-off, deployment queues, waiting on approvals.

 

Time in Status is the metric that shows you exactly where issues are accumulating dwell time. Not on a per-ticket basis (though that's useful too), but in aggregate, across your entire workflow.

A tool like Time in Status Reports by RVS Softek surfaces this directly. You get a breakdown of how long issues spend in each workflow stage:

• by status
• by assignee
• by time period

If "In Review" is averaging four days when it should average one, that's your bottleneck. You didn't have to guess; the data just told you.

Set a limit for how long issues should stay in each stage. If issues go beyond that limit at any stage, that’s where you should start looking for problems.

3. Transition History: Are Issues Moving Forward or Bouncing Around?

Time in Status tells you how long issues stay in a status. Transition history tells you how they got there, and whether they've been there before.

This is where things get interesting. If you see an issue that has moved from In Progress → In Review → In Progress → In Review three times, that's not a workflow problem. That's a quality or communication problem dressed up as one.

Frequent back-and-forth between statuses usually means one of three things: unclear criteria for what "done" looks like at each stage, rework happening silently, or a hand-off that's breaking down between teams. None of those show up in your sprint velocity. All of them show up in the transition history.

Look for issues that are revisiting statuses they've already been through. A small number is normal. A pattern is a signal.

4. SLA Teams: Percentile Data Is What You Actually Need

If you run a support or ops team, "average time in status" isn't enough. Averages lie. One ticket resolved in five minutes and one resolved in five days gives you a 2.5-day average, which describes neither ticket accurately. Here is how: 

5 minutes+5 days/2 ​=25 minutes+720 minutes​/ 2 =725 minutes​/2 =362.5 minutes≈6 hours.

So, the average resolution time is around 6 hours, which is an inaccurate representation of both tickets. One ticket was solved in five minutes and the other in five days, but the average makes it seem like both tickets took around the same amount of time to resolve, which doesn't reflect the reality of the individual cases.

That’s why Median and 85th percentile calculations are the standard for SLA reporting, and they should be the standard for workflow health checks, too. The 85th percentile tells you what the experience looks like for the outliers, the tickets that are straining your SLA commitments.

RVS Softek's Time in Status Reports surfaces both. They're not buried in a settings menu or a configuration layer; they're first-class report types you can pull up immediately. If your P1 SLA is four hours and your 85th percentile resolution time is six, you know exactly what you're dealing with.

5. Trend Analysis: Catch Slowdowns Before They Compound

A single health check gives you a snapshot. What you actually want is a trend.

Cycle time creeping up by 10% each sprint doesn't break a delivery, until it does. Lead time growing quarter-over-quarter is invisible in a single sprint review but obvious when you look at three months of data.

Time in Status trend reports let you track cycle time, lead time, and resolution time over time. If "In Code Review" is taking 20% longer this quarter than last, that's worth investigating now,  before it becomes a delivery problem or a team morale problem.

Conclusion

The teams that get the most out of workflow data aren't the ones who run a single health check. They're the ones who build it into their operating rhythm — a monthly or quarterly review of where time is going, what's trending in the wrong direction, and whether the workflow changes they made last quarter actually worked.

Jira already has all the data you need to do this. Status transition data is being generated every time an issue moves through your workflow. The question is whether you have a way to surface it.

 Start a free trial with RVS Time in Status Reports, which is built specifically for this, with workflow visibility without the overhead of a full analytics platform. Install it, run your first report, and find out what your workflow is actually doing. 

It usually takes about ten minutes to see something worth acting on.