How to find bottlenecks in Jira
Every team can feel that work gets stuck somewhere — but “somewhere” is usually a guess. To find the real bottleneck in a Jira workflow, measure time in status: how long issues actually sit in each status on their way to done. The status with the highest total waiting time is your constraint — not the fullest column on the board, and not what the control chart shows. Here’s the method, and why the obvious shortcuts don’t work.
Why the board doesn’t tell you
The obvious move is to look at the board and find the fullest column. It’s a trap:
- The board shows a snapshot, not waiting time. A column can be full because work piles into it faster than it leaves (a real bottleneck) — or simply because it holds long-lived items that aren’t actually stuck. The count at one moment can’t tell the two apart.
- The control chart shows the total, not the location. Jira’s control chart gives an overall cycle-time cloud, but it doesn’t break the time down by status, so it can’t point at which step is the constraint.
What actually identifies a bottleneck is time-in-status: how long issues sit in each status on their way to done. The status that accumulates the most waiting time is your constraint.
The method
- Measure time-in-status per status, not just the end-to-end cycle time, for the issues in scope — see how to measure cycle time in Jira for the start/done basics.
- Rank statuses by waiting time. The top of that list is the bottleneck — in most teams it’s a review, QA or a “blocked/waiting” state, not the “in progress” doing-the-work state.
- Measure in working hours. Skipping weekends and holidays stops a status looking slow just because work sat over a Saturday, so you fix the real constraint, not a calendar artifact.
- Confirm it’s a trend, not one outlier — check the bottleneck holds over several weeks before you re-engineer around it.
Doing it without exporting changelogs
Linger computes time-in-status from the issue changelog in your tenant and flags the bottleneck for you — per issue and across a project or board, in real working hours — so you skip the export-to-spreadsheet step entirely. For how this differs from Jira’s native chart, see control chart vs time in status.
The takeaway
The fullest column isn’t the bottleneck — the status with the most waiting time is, and the board can’t show you that. Rank your statuses by time-in-status in working hours, confirm the trend, and you’ll fix the step that’s actually holding work up instead of the one that merely looks busy.
Frequently asked questions
- How do I find the bottleneck in my Jira workflow?
- Measure how long issues spend in each status (time-in-status) and look for the status with the highest wait. That status — often a review, QA or blocked state — is the bottleneck. Jira does not surface this directly, so you compute it from the changelog or use an app.
- Can Jira show where issues get stuck?
- Not directly. The board shows current counts per column, and the control chart shows overall cycle time, but neither tells you which status accumulates the most waiting time. Time-in-status, broken down by status, does.
- Is a column with lots of issues the bottleneck?
- Not necessarily — a column can be full because work arrives faster than it leaves (a real bottleneck) or just because it holds long-lived items. Time spent waiting in the status is a better signal than the count at a single moment.
- Should bottlenecks be measured in working hours?
- Yes — measuring in real working hours (skipping weekends and holidays) avoids flagging a status as slow just because work sat over a weekend, so you fix the real constraint rather than a calendar artifact.