“Reviews are slowing us down.” “Too much work keeps rolling into the next sprint.” “We’re spending all our time fixing bugs.”
These concerns come up in retrospectives and delivery meetings because people experience different parts of the workflow. A developer remembers waiting for feedback, a tester remembers urgent requests arriving together, and a product manager sees planned features moving later. Each observation may be valid, but deciding what to change requires a broader view.
Jira contains the work items behind those experiences. The difficulty is turning their history into an answer the team can use.
Why a detailed report can still leave you guessing
A table of status durations helps you inspect individual work items. Across a larger report, however, patterns take more effort to find. You need to compare rows, identify exceptions, and check whether a few unusual cases are shaping the overall result.
Averages alone can leave important questions unanswered. A long average review time might reflect a queue affecting most items or a handful of complex requests. A busy sprint might contain mostly bugs, but that does not tell you how much effort those bugs required. Two similarly estimated stories might have very different durations because they followed different paths through the workflow.
Those differences matter when choosing an action. Adding review capacity, changing refinement practices, and investigating a recurring testing problem solve different problems. Before choosing one, the team needs to see where the evidence points.
Give each chart a question to answer
Charts help make those differences visible. A stacked bar shows which stages dominate a duration. A histogram reveals how widely durations vary. A scatter plot lets you examine whether similarly estimated items behave similarly.
That is the practical purpose of the new chart builder in Time in Status. It lets you create several visual views of a report inside Jira, then return to the underlying work items when a pattern deserves investigation.
The builder offers 13 chart types, configurable categories and aggregations, and appearance settings. You can build charts from scratch or from selected table cells—and create, customize, and view them directly in your Jira dashboard through Time in Status gadgets.
Here are eight questions to explore, using an example report of 159 resolved work items over a 30-day period.
1. Where does review time deserve attention?
A general complaint about slow reviews is difficult to act on. Start by identifying the work most affected and examining what it has in common.
Setup: Stacked bar · Assignee · Average · In Progress, On review, Testing
What the example shows: Review dominates several bars, with two groups averaging more than 80 hours in that status.
Next step: Inspect those work items for shared reviewers, approval requirements, or dependencies. Assignee groups help locate affected work; they do not identify who caused a delay or measure individual productivity.
2. Which work associated with multiple sprints takes longer?
Repeated carryover can become so familiar that the team stops examining it. Comparing durations by Sprint helps identify work worth bringing back into the retrospective.
Setup: Bar · Sprint · Average · Total
What the example shows: Several long-duration groups have multiple sprint names in their labels.
Next step: Check whether those items were blocked, changed scope, or entered a sprint before they were ready. These categories represent sprint values and combinations; the chart does not calculate a sprint’s spillover rate or show a chronological trend.
3. Does urgent work move through QA faster?
Priority expresses an expectation. Comparing time before testing with time in testing helps you examine whether the workflow supports it.
Setup: Column · Priority · Average · Testing, Ready for Testing
What the example shows: Highest-priority items average roughly 23 hours in Testing, considerably longer than Medium- and High-priority items.
Next step: Check the counts and work types behind each bar. Determine whether time accumulates before testing or within the testing stage, and whether a few complex items dominate the average.
4. What kinds of work make up the completed items?
A team can complete plenty of work while making less progress on planned features than expected. Looking at the work mix gives that conversation a concrete starting point.
Setup: Donut · Type · Count · One numeric series populated for the included items
What the example shows: Bugs and tasks account for most items, while stories represent a smaller share.
Next step: Compare the mix with the team’s priorities and a previous period. This shows item counts, not effort or resource allocation: ten small bugs may require less work than one substantial story.
5. How much does duration vary for the same estimate?
When similarly estimated items finish at very different times, the team needs to understand what happened between starting and finishing them.
Setup: Scatter · Work item key labels · Aggregation off · Story Points on X, Total on Y
What the example shows: Items with similar estimates appear across a wide range of durations.
Next step: Compare status histories for similarly estimated items with very different totals. Look for blocked stages, review delays, or repeated work. Keep the comparison within a team where possible, because estimation scales can differ.
6. What does the average total time hide?
One average can be a poor description of a report containing both quickly completed items and much longer-running work. A histogram makes that variation easier to examine.
Setup: Histogram · Aggregation off · Total
What the example shows: Several duration clusters, including a prominent group near the upper end of the displayed range.
Next step: Check whether those groups contain different work types or workflow paths. The chart measures total time across the included statuses; confirm the status selection and reporting window before treating it as full cycle time.
7. Which projects accumulate the most review time?
A manager overseeing several projects needs a way to identify where a closer process discussion would be useful.
Setup: Stacked column · Project · Average · In Progress, On review, Testing
What the example shows: Team Nova’s project averages around 70 hours in review.
Next step: Inspect its review-heavy work items for shared requirements or dependencies. Compare work types, volumes, calendars, and status definitions before drawing conclusions across projects.
8. How does the balance of workflow time differ by work type?
Different kinds of work may spend their time in different stages. A percentage view helps identify which stage deserves attention for each type.
Setup: 100% stacked bar · Type · Average · In Progress, On review, Testing
[Insert image 08 — Share of time by workflow stage and work type]
What the example shows: Review represents most of the displayed time for bugs and tasks, while testing has a larger share for security bugs.
Next step: Examine those proportions alongside absolute durations. The percentages cover the selected stages, and review or testing can include both active work and waiting.
Keep the views you need on your Jira dashboard
You can build these charts in eligible reports on the Time in Status global page or directly in dashboard gadgets. Create multiple charts, customize their titles, colors, legends, axes, backgrounds, and spacing, then move and resize their windows within the gadget.
A retrospective might benefit from a review-duration chart alongside a work-mix donut. A delivery review might need a project comparison and a total-time histogram. New charts are Live, so they update with the report data.
To create your first view:
- Open an eligible report in Table view and set its scope and reporting periods.
- Add the Jira fields and numeric columns you need.
- Select Charts → Create chart, or create a chart from selected cells.
- Choose the type, categories, series, and aggregation.
- Customize the appearance and save the report or gadget configuration.
Categories include Assignee, Sprint, Priority, Type, Project, Status, and Work item key. Numeric series can include status durations, Total, and Story Points, with Sum, Min, Max, Count, or Average aggregation.
Changes to periods and work schedules update Live charts, while changing the report’s type or scope removes its charts. Selection-based charts follow selected columns and row positions, so check their scope after rearranging the table.
Start with the discussion that keeps repeating
Choose one question your team has raised more than once without resolving it. Build the corresponding chart in Time in Status and use it to identify the work items worth discussing.
The first useful result might be a specific approval dependency, a group of repeatedly carried-over items, or a work mix that differs from the plan. Save that view in your report or Jira dashboard, agree on one action, and return to it with updated data at the next review.
