A time in status table tells you everything and shows you nothing. I took one time in status report, built four charts from it, and used each one to answer a single workflow question: where time accumulates, whether long waits are the rule or the exception, which work items to check first, and whether estimates match reality. Along the way, one chart gave me a completely wrong picture because of a single checkbox. Details below.
Disclosure: I work at SaaSJet, the team behind the Time in Status app by SaaSJet used in this post.
The problem with a perfectly good table
Jira records every status change in each work item's history. Time in status is simply the time between those changes: how long an item sat in In Progress, On review, Testing, and so on.
A time in status report turns that history into a table. Which is great until the table has 100+ rows and a dozen status columns. At that point, the work items that need attention look exactly like the ones that don't. You end up scanning cells, and nobody does that during a stand-up.
So instead of reading the table, I started asking it questions, one chart per question.
Question 1: Where does time accumulate across projects?
Setup: Stacked column · Categories: Project · Aggregate: Average · Series: In Progress, On review, Testing
I compared two projects. Using Average instead of Sum matters here: the projects have different numbers of work items, and a sum would just reward the smaller one.
The result was more interesting than I expected. Work items in the Design project took nearly twice as long on average as those in Core App, and most of that difference was in review. In Design, items spent about 2.5 days On review, which is longer than the 2.2 days they spent In Progress. Review took more time than the work itself.
Before you trust a chart like this: compare only the statuses both projects actually use. Design has no Testing status at all, so part of the height difference comes from a different workflow, not slower work. This chart tells you where to look closer. It is not a team ranking.
Question 2: Is "long review" a pattern or a few bad cases?
Setup: Histogram · Series: On review · Aggregate: off
An average of 2.5 days can mean two very different things: most items wait about 2.5 days, or most pass quickly while a few sit there for weeks. The table and the average look identical in both cases. A histogram doesn't.
For the Design project, I narrowed the report to items that actually went through review:
project = Design AND status WAS "On review" Without that filter, items that never entered review show up as a tall bar at zero and distort everything.
What the histogram showed: 49 of 63 work items left review in under six days. Eleven took six to seventeen days. Three stayed in review for two and a half to almost six weeks.
So the average described nobody. Not the typical item, and not the problem work items. Those three long cases were dragging it up.
In latency terms, this is the p50/p85 conversation. Roughly 78% of work items left review within six days. "Most reviews finish within a week" is a far more useful expectation for the team than "the average review takes 2.5 days".
What to do with this: start with the far right. A month in review almost never means a month of reviewing. It usually means blocked, waiting for a decision, or forgotten. Then look at the middle group: a dozen items regularly taking one to two weeks is a process conversation, not a list of exceptions.
Question 3: Which work items should I open first?
Setup: Grouped bar · Categories: Work item key · Series: In Progress, Ready for Testing, Testing
Once you know there are outliers, you need their keys. Here's the trick that made this chart readable: sort the table by the status you care about, select the top 8–10 rows, and build the chart from that selection. With 30+ items, the bars turn into threads and you can't compare anything.
Two items spent more than 12 hours in In Progress, about four times longer than anything else in the selection. Their Ready for Testing and Testing times were short, so the delay happened during development, not in the handoff to QA.
A long bar tells you where to look, not why. Check whether the item was blocked, reassigned, or just bigger than it looked.
Question 4: Do items with the same estimate take the same time?
Setup: Scatter · X: Story Points · Y: Total · Labels: Work item key · Aggregate: off
This is the chart you simply can't get from a table. Each point is one work item, placed by its estimate and the time it actually spent in the workflow.
I used one project only (estimation scales differ between teams) and filtered to finished, estimated items:
project = "Core App" AND statusCategory = Done AND "Story Points" > 0 
The overall trend made sense: bigger estimates generally took longer. But within the same estimate, the spread was huge. Work items estimated at 3 points took anywhere from a few hours to about 12 days. One 22-point item finished faster than the slowest 3-pointer. A 17-point item spent almost four weeks in the workflow.
A wide spread doesn't prove the estimates were bad. It shows where the workflow added time that no estimate could predict. The next step is to take two items with the same estimate and very different totals and compare their status histories side by side.
The chart that lied to me (and the gotchas I'd check every time)
My first version of the scatter plot was useless. Dozens of points lined up at exactly ~62 days, regardless of the estimate. A 1-point item and a 22-point item looked identical.
62 days turned out to be the length of my reporting period. The total was the sum of all 13 statuses in the report, including Done. An item closed on day two kept "accumulating" time in Done until the end of the period. The chart was showing when items were created and closed, not how long the work took.
The fix was to keep only statuses where work is actually happening (In Progress, On Review, Ready for Testing, Testing, Blocked) and remove Done, To Do, Backlog, and anything that means "not started" or "already finished". The y-axis dropped from 69 days to 28, and the real picture appeared.
This isn't a quirk of one tool. Open-source flow tools like jira-agile-metrics make you define where work starts and ends in their config for exactly this reason: cycle time only means something once backlog and done time are out of it.
My checklist now, before reading any time in status chart:
- What's inside Total? If it includes Done or backlog statuses, you're measuring age, not work.
- Are unfinished work items in the data? Open items keep accumulating time until the end of the period. Filter with
statusCategory = Donewhen you compare durations. - Are there empty values? Items without story points or without a given status can pile up at zero.
- Duplicate or legacy statuses? Workflows change, but history doesn't. My report had both "Todo" and "To Do". Exclude one and forget the other, and your numbers quietly drift.
- How does your team mark blocked work? If it uses Jira's Flag instead of a Blocked status, time in status won't show blocked time at all. It will look like regular In Progress time.
- Sum or Average? Use Average when groups have different sizes.
- Same workflow? Comparing projects with different statuses compares workflows, not teams.
How the charts are built
All four charts came from table reports in Time in Status app. You either select a range of cells and choose Chart range, or open Charts → Create chart in the sidebar and pick the categories, series, and aggregation. The builder has 13 chart types, and the charts stay Live, so they update when the report data changes. You can also add them to a Jira dashboard through the app's gadgets. More in the original article and the Integrated charts documentation.
If you'd rather script this, jira-agile-metrics is an open-source CLI that pulls cycle time, histograms, and scatter plots straight from the Jira API. I wanted the charts inside Jira, next to the table I was already using, so I went with the app.
Over to you
Which workflow question keeps coming up in your retros without a clear answer? And has a chart ever confidently shown you something that turned out to be a data artifact? I'd love to hear your stories in the comments.
