How to run a Jira “workflow health check” using 3 reports

[#1]

Time in Status → Status Count → Transition Count (a.k.a. Traffic Jam, Boomerang, Ping-Pong)

Most teams don’t have a “bad workflow.” They have a workflow that quietly accumulates debt until one day it starts behaving like a supermarket checkout line right before a national holiday.

A workflow health check is a simple routine to answer 3 questions:

1. Where does work get stuck? (bottlenecks)
2. Where does work bounce back? (loops / rework)
3. Where does work hand off too much? (friction / ping-pong)

The nice part: the Time in Status app already maps to these questions directly:

• Time in Status Report → bottlenecks
• Status Count Report → loops / rework
• Transition Count Report → handoff friction

That mapping is literally what the reports are designed to surface.

Let’s turn those three reports into a repeatable, mildly entertaining 30-minute ritual.

Step 0: Set the scope (or your report will tell you “everything is broken”)

Before you diagnose anything, pick a scope that matches the question.

Use the two time filters correctly (they’re different on purpose)

Time in Status has:

• Work items period = which issues you include
• Report period = which dates you calculate within

Example (very normal): include issues from the last 30 days, but calculate time only for the last week.

If your charts look “too old,” “too large,” or mysteriously empty — it’s usually a scope mismatch.

Pick the right calendar (because weekends love ruining metrics)

If you’re measuring flow for teams that don’t work 24/7, use a work schedule (calendar) so the app converts elapsed time into business time. Otherwise your “review took 4 days” might really mean “it sat there Friday night to Monday morning like a forgotten houseplant.”

Pro tip: don’t mix workflows unless you enjoy chaos

If you report across projects where statuses mean different things, your results will look like a smoothie made of pizza and cereal. It’s technically “data,” but no one should consume it.

Step 1: Find bottlenecks with Time in Status

Time in Status app tells you where time goes — which is the fastest way to spot bottlenecks.

What you’re looking for

A “bottleneck” status is usually:

• high total time, and/or
• high average time, and/or
• a big share of overall time (great for charts)

Common suspects:

• In Review
• Waiting for QA
• Blocked
• Waiting for Customer
• anything that sounds like “we can’t move until…”

The trick: group statuses into phases (so your workflow becomes readable)

Instead of staring at 17 statuses like they’re a password you forgot, use Status Groups to roll them up into something humane (Dev / QA / Review / Waiting). Status Groups are meant to sum time across statuses so you can calculate things like Cycle Time and Lead Time in your own workflow language.

Ask “queue or work?”

When a status is slow, don’t jump straight to “people are slow.”
Ask:

• Is it active work time (coding/testing) or waiting time (queue/approval)?
• Is the policy unclear (“What does ‘Done’ mean here?”) or the capacity limited (“One reviewer for 12 devs”)?

Deep thought, delivered gently: a bottleneck is rarely a person. It’s usually a systemic appointment calendar conflict between demand and capacity.

Step 2: Find loops (rework) with Status Count

Status Count shows how many times an issue entered each status. If an issue hits “In Progress” three times, Status Count for “In Progress” = 3. This is your “boomerang detector.”

What you’re looking for

• Statuses with unexpectedly high counts (especially “In Progress”, “QA”, “Reopened”, “Backlog”, “To Do”)
• Patterns like: In Progress → Testing → In Progress
  (aka: “Congrats, we invented time travel.”)

What high Status Count usually means

• unclear acceptance criteria
• quality gaps (tests, environment, definition of done)
• work started too early (not ready)
• dependencies discovered late

A simple rule

• High time + low count = stuck/waiting
• Low time + high count = thrash (constant bouncing, context switching)
• High time + high count = the workflow equivalent of a washing machine… with bricks inside

Step 3: Find handoff friction with Transition Count

Transition Count shows how often issues move between specific status pairs. It’s literally counting “In Progress → In Review”, “QA → Dev”, etc. This is your “ping-pong detector.”

What you’re looking for

Status pairs with high back-and-forth counts, like:

• Dev → QA → Dev

• In Review → In Progress

• Waiting for Customer → In Progress → Waiting for Customer (support teams feel this in their bones)

What it usually means

• handoff requirements aren’t clear (“what does QA need to accept this?”)
• too many reviewers/approvers with inconsistent standards
• missing “definition of ready” between stages
• work is being tossed over walls instead of collaborated on

The sneaky insight

High Transition Count often looks like “we’re moving fast” because things are constantly changing status. But constant motion ≠ progress. It might just be a very motivated hamster wheel.

The 3-signal “workflow diagnosis” matrix (use this in retros)

Now combine the reports like a workflow doctor:

1) Bottleneck (Traffic Jam)

• Time in Status is high in one status
• Status Count and Transition Count are normal-ish
  Likely cause: queue/capacity/policy

Fix ideas:

• limit WIP entering that status
• increase capacity (more reviewers, rotate duty)
• tighten entry criteria (definition of ready)

2) Rework Loop (Boomerang)

• Status Count is high for the same few statuses
• Transition Count often shows the same back-and-forth pairs
  Likely cause: quality, unclear requirements, incomplete handoff

Fix ideas:

• make acceptance criteria testable
• add “ready” checklist before QA/review
• add lightweight pairing on risky changes

3) Handoff Friction (Ping-Pong)

• Transition Count is high between two stages
• Time might be moderate, but progress feels… exhausting
  Likely cause: misaligned expectations between roles/stages

Fix ideas:

• agree on “what good looks like” for the handoff
• reduce batch size (smaller PRs/issues)
• introduce a short sync at the boundary (not a meeting—more like a pit stop)

Make it stick: save it, share it, dashboard it

If you want this to become a habit (and not a one-time “we should do this more often” fairy tale):

• Save the setup as a preset, and reuse it.
• Put it on a dashboard gadget so the team can see it without opening the app (choose report type, filters, date ranges, calendar; table or chart).
• Keep the scope reasonable so it stays fast and meaningful.

A quick warning label (because we like our metrics non-toxic)

Time in Status is great at replacing micromanagement with transparent, time-based metrics. So… don’t turn it into a leaderboard. Use it like a thermometer:

• If the temperature is high, you don’t yell at the thermometer.
• You figure out what’s on fire.

Conclusion: a healthy workflow feels boring (in the best way)

A good workflow health check doesn’t produce drama. It produces clarity. With these three reports, you can reliably spot:

• where work stalls (Time in Status)
• where work bounces back (Status Count)
• where work ping-pongs between stages (Transition Count)

And once you can name the problem precisely, fixes get smaller, kinder, and way more effective.

Because the goal isn’t to run faster. It’s to stop running in circles — unless you’re doing it for fitness and emotional support.

Time in Status app | Book a demo call