Your dashboards reward speed. A skipped review looks exactly like speed.
Your dashboards reward speed. A skipped review looks exactly like speed.
A quick disclosure before I start: I'm a co-founder of MetaFrazo, an app on the Atlassian Marketplace, and the last part of this post describes how we surface this pattern in our product. Everything before that is a governance problem any Jira admin can look at on their own, which is really what I want to talk about.
In theory, a governance-conscious admin could check the health of every project by hand. Each morning, open a few reports side by side: how often an issue jumps straight to done, how often "done" work comes back, how much is silently stuck. Read them project by project. In a five-project instance, that is a ten-minute habit. In an estate with eighty projects, nobody sustains it past the second week.
So the exercise quietly stops. Not because it stopped mattering, but because it does not scale. And that is precisely the moment the risk begins, because the signals keep changing whether anyone reads them or not.
Jira is never static. New projects are created, teams fall behind, deadlines compress. A workflow gets bypassed once under pressure, and then again, because the first time nothing bad happened. Each of these is a local, reasonable decision. None of them looks like a problem on its own.
Over time, though, those individual decisions accumulate into a pattern that no single dashboard shows. Velocity still looks fine, often better, because skipping a review makes a team faster on paper. Nothing stops working. And a project can drift a long way outside its own governance boundaries while every chart on the wall stays green.
The uncomfortable part is that none of this is hidden data. Every skipped step, every reopen, every stuck issue is already recorded in your Jira event history. The information is there. What is usually missing is a single place to read it, and someone with the time to read it every morning.
Three signals worth watching
If I had to reduce "is this project governing itself" to a short list, it would be these three:
Workflow bypass: how often an issue reaches a done status directly from a not-started one, skipping everything in between.
Reopen rate: how often completed work comes back, which is your quietest quality signal.
Stuck work: how much sits in a status far longer than comparable issues, blocking delivery without ever showing up on a velocity chart because it never moves.
None of these is dramatic on its own. It is the concurrency that matters. A project where all three are climbing at once is telling you something structural, not incidental.
You can approximate this by hand
You do not need any app to start looking. A few things you can do today in a vanilla Jira:
For reopens, a query like status changed FROM "Done" TO "In Progress" AFTER -13w (adapt to your status names) gives you a rough reopen signal for the last quarter. JQL has no GROUP BY, so you group by project in the results view, not in the query itself. For stuck work, there is no native "time in current status" sort, but ORDER BY statusCategoryChangedDate ASC gets you close: the issues whose status category changed longest ago float to the top, and the ones sitting well beyond their project's norm are the ones you are after.
Bypass is the hard one in plain JQL. You are really looking at the transition history of issues that reached a done status, checking whether they passed through anything on the way or jumped straight there from a not-started status, which usually means sampling issues and reading their history one at a time.
That last part is exactly where the manual approach breaks down. Reopens and stuck work you can approximate. Bypass hides in the transition history, one issue at a time, and there is no clean way to ask "which issues reached done without going through the middle" across a whole portfolio at once. That is the gap that pushed us to build something.
How we surface it in MetaFrazo
Per my disclosure above, this is the product part. We compute a single score per project from those signals, built from Jira's workflow events as they arrive rather than from a periodic export. Each project gets a gauge and a severity label. Stuck work also gets a view of its own, because once a project starts climbing you need the specific issues that have stopped, with names and owners, not just a number.
Screenshot 1 · Bypass Risk Score per Project
A gauge for every project with a scoreable history. A genuinely clean project, with no detected bypass at all, is not on the grid; its absence is the good news. The value is not any single reading. It is the morning a gauge that sat quietly for months moves up a band, before anyone has manually cross-referenced anything.
The score tells you where and how serious. It does not tell you why, or whether it is one person's habit or a whole team under strain. For that you look at who.
Screenshot 2 · Actor-Level Bypass Fingerprint
The fingerprint ranks the people behind those events by how much they contribute to the bypass and reopen activity in view. The shape worth looking for is concentration: one account carrying most of the skips and reopens while everyone else sits far below. If you find it, it is worth asking whether that account is simply the one everyone routes around a slow gate. An even spread across many people points the other way entirely: usually the workflow itself, or the pressure the team is under, not any individual.
Two things are worth being explicit about, because they change how you read this. The identifiers are pseudonymous Atlassian account IDs, never names or email addresses. Pseudonymous, not anonymous: they can still be linked back to a person, which is exactly why there is a data-subject erasure path over them. The goal is seeing the pattern, not building a case against a person. And a bypass is not automatically misconduct. Sometimes routing around a workflow is the reasonable thing to do under a broken process. The number is a prompt to look, not a verdict.
Screenshot 3 · Stuck-in-Status Detector
This is the view for the part the JQL above could only approximate: it surfaces the issues sitting well beyond the normal time their neighbors spend in the same status, across every project at once. Bypass is work moving too fast through the gates. A stuck issue is work that has quietly stopped. You watch them together because they fail in opposite directions, and a project can be doing both.
There is an optional analysis layer that helps read the gauges faster, summarizing which projects sit above the portfolio average. It does not find the risk; the analytics do that. It does not decide what to do; you do. It just shortens the distance between seeing a gauge and understanding it.
All three of these views are in our base Pro edition, so none of this is an enterprise-only story.
Why continuous beats a snapshot
A manual audit is a snapshot. It describes your configuration at one moment and cannot tell you what changes tomorrow. Jira keeps evolving every day, so today's clean picture may not hold in a few weeks. Whichever way you tackle this, by hand or with tooling, the thing worth aiming for is catching drift while remediation is still one conversation, not a portfolio-wide cleanup.
Workflow bypass rarely arrives as a scandal. It arrives as a series of small, defensible choices. A gate skipped to make a release. A review waved through because the person is trusted. A stuck ticket everyone assumed someone else was watching. Each one is reasonable. None trips an alarm. And a dashboard built to celebrate throughput will happily show a project moving faster, right up until something that never got checked comes back as an incident.
I'm curious how others here handle this. Do you actively watch for workflow bypass, or does it only surface after something breaks? And has anyone found a clean way to detect skipped transitions across many projects in plain JQL? Genuinely interested in how you approach it.
Atlassian, Jira and the Atlassian logo are registered trademarks of Atlassian Pty Ltd.
Was this helpful?
Thanks!
Maria Reisinger _MetaFrazo_
1 comment