The method, in one paragraph
Take every issue your team finished in the last quarter. For each status in the workflow, find the median time issues spent there. Rank the statuses by that median. The top of that list is where your delivery time actually goes. Everything below is detail.
It sounds too simple to be worth doing, and most teams have never done it — because until you have a table of time per status per issue, you are guessing, and the guess is almost always "the developers are slow".
What the table looks like
| Status | Median | 85th pct | Average | Issues |
|---|---|---|---|---|
| To Do | 1d 4h | 6d | 2d 2h | 48 |
| In Progress | 1d 6h | 3d 1h | 1d 20h | 48 |
| In Review | 4d 2h | 11d | 5d 6h | 46 |
| Ready for QA | 6h | 2d | 14d 3h | 44 |
Two things to notice here, and one of them is a trap.
In Review is the bottleneck. Its median is more than twice anything else, and its 85th percentile says one issue in seven waits over a week and a half for a reviewer. Nobody is coding slowly; everybody is waiting for a colleague to look at something.
Ready for QA is not. Its average of 14 days is the largest number in the table and it means nothing: the median is six hours. A handful of issues were dumped there and forgotten, never closed, and they are still accumulating time right now. The fix is to close them, not to hire a tester.
Three traps
1. The average
One issue opened in March and never closed contributes six months to every average it touches. Medians ignore it; averages are hostage to it. Always read them side by side — the gap between median and average is itself the signal that you have abandoned issues.
2. The status nobody measures
Bottlenecks hide in statuses that have no owner. In Progress belongs to a named person whose day is organised around it. In Review, Blocked, Waiting for Customer and Ready for Deploy belong to nobody in particular, so work accumulates there without anybody feeling responsible for the pile.
Those are precisely the statuses a team leaves out of its report, on the grounds that "nothing happens there". Nothing happening is the problem.
3. Revisits counted as short stays
A status that issues keep returning to is a bottleneck even when each visit is brief. Three separate one-day visits to In Progress is not a fast status — it is a rework loop, and a report that shows only the current visit will rate it as healthy.
This is the same blind spot that makes Jira's own Days in column reset. Count visits, not just duration: a status with a high revisit rate is telling you that the step before it is releasing work that is not ready.
What to do with the answer
A bottleneck is not solved by asking the people in it to work harder; by definition they are the busiest step. The three things that do work:
- Limit what enters it. A WIP limit on the column before the bottleneck stops work piling up faster than it can leave.
- Add capacity to that step specifically. If review is the constraint, more reviewers helps and more developers makes it worse.
- Shrink the work. Smaller pull requests are reviewed faster than large ones by more than their size difference.
Then measure again in a month. The bottleneck will have moved to a different status — that is what success looks like, not a workflow with no bottleneck at all. There is always a slowest step; the goal is for it to be a step you chose.
Getting the table
TimeInColumn produces exactly this from a project or a JQL filter: one row per issue, one column per status, with average, median and 85th percentile underneath, and revisit counts per issue. Group it by assignee, sort by any column, export it to CSV.
It reads your existing Jira history, so the answer is available on the first run rather than a quarter from now, and it installs into your browser without a Jira administrator.