Average Time in Status(2.7.5)

Knowing that a ticket took 10 days to complete tells you very little. Knowing that 8 of those days were spent waiting in “In Review” tells you exactly where to intervene. This visual shows you the average time issues spend in each workflow status per project — revealing where work gets stuck, not just how long it takes overall.

Different projects will have different bottleneck profiles. One may be slow in review, another may have a backlog that issues sit in for days before anyone picks them up. Seeing both side by side helps you direct process improvements to the right stage.

What you can conclude

• A status with a disproportionately high average time is where work waits longest — focus improvement effort there, not on execution speed.
• If the same stage (e.g. “In Review”) is slow across all projects, the constraint is shared — a common resource or process step rather than one team.
• A project where “To Do” dominates all other stages is holding work before it starts, not while it runs — grooming is the place to look first.

Completed statuses are shown, and are not ranked

• Statuses Jira places in its Done category are kept in this chart. Time sitting in a completed status is a real measurement and can be worth seeing.
• They are not eligible for the Top bottleneck KPI. An issue that has reached a completed status is not queued behind anything, so ranking one as the bottleneck would point effort at a stage with no queue.
• Read their dwell carefully: the clock measures the gap between one status change and the next, so a completed status only produces a measurement for issues that later left it — a reopen, or a move from one completed status to another. It is a sample of departures, not time since completion for all finished work.
• Whether reaching a completed status meant the work was delivered or abandoned is MetaFrazo's default reading of the status name until your organization's own classification is recorded. Completed statuses in settings shows which reading applies; to change it, open a support request. Whether a status is completed at all comes from Jira's own status category, not from us.
• Whether a status is completed is decided per project, because the same display name can be a completed status in one project and an open one in another; the Top bottleneck ranking leaves it out only in the projects where it is completed.
• Where one display name covers Jira statuses that disagree within a single project (or, where the project never showed the status itself, across the organization), or a status has not been seen in the event history, the classification is left blank rather than guessed, and the status stays in the ranking.

How this chart works

Grouped bar chart showing average hours issues spend in each workflow status, grouped by project. Use the project filter to focus on a single team.

What this measures, and what it leaves out

• The clock runs between one status change and the next, so a status only produces a measurement for issues that later left it. Work sitting in a status right now contributes nothing until it moves — a stage where work is currently parked can therefore read faster than it feels.
• No upper limit is applied to a wait. A genuinely long wait is reported at its full length and counts toward the average, so one very long wait can lift a cell far above its median. Where average and median diverge sharply, a small number of long waits is driving the stage.
• Every bar carries the number of measurements behind it. A bar resting on one or two measurements is a single observation, not a trend, and is worth checking against the underlying issues before acting on it.
• The median and the 90th percentile behind a bar are published only where a project, status and day had at least five departures. Below that they are left blank rather than computed from one or two waits, because a 90th percentile of one measurement is that measurement. The average and the count of measurements are still published, so a blank median marks a small sample, not a missing measurement.

How a bar is composed, and what a missing bar means

• The measurement behind this chart is taken per project, per status, per day. Each bar is the mean of that status's daily readings across the whole selected range, weighted by the number of issues that left the status on each day—a day on which forty issues departed counts forty times as much as a day on which one did. That weighting is what makes a bar the range's average wait rather than an average of daily averages, and it is why a single unusual day no longer sets a bar's height on its own.
• The Top bottleneck figure above the chart is composed the same way, one step wider: it rolls the same daily readings up across days and across the projects where the status is eligible, so the status it names is the one with the longest weighted average wait over the whole range, not the worst single day of any one project. A status can therefore top that ranking without owning the tallest bar in any single project.
• A project with no reading at a status draws no bar at all, and is left out of that status's shared tooltip. That is not the same as a measured zero. A missing bar means no issue of that project left that status inside the range, so there is nothing to time; a bar resting at 0.0h is a measurement—issues did leave, and the wait was short enough to round to zero at the precision shown. Reading a gap in a row of bars as a fast stage is the mistake this distinction exists to prevent.

A status is identified by its Jira status id, so a status that was renamed appears once, under its current name. Waits are chained on the issue itself rather than on its key, so an issue moved to another project keeps the wait it was in when it moved; that wait is counted in the project where the issue left the status.