Your Jira Report Found the Delay. Now What?

[#1]

Suppose a sprint misses its target. You open a Time in Status report and find several work items that spent a long time in Testing. Fair enough—Testing looks suspicious. Then the questions begin.

“Was Testing slow for most work items, or did one monster ticket distort the result?”

“Did bugs wait longer than stories?”

“Was this sprint unusual?”

“Does the same problem exist in other projects?”

The report is not wrong. It has shown exactly how long each work item spent in each status. The problem is that the conversation has moved from “What happened to this ticket?” to “Is there a pattern across our work?”

Answering that second question by scanning hundreds of rows is possible. So is assembling IKEA furniture without looking at the instructions. Neither is the best use of a Friday afternoon.

This is where Pivot Mode in Time in Status by SaaSJet becomes useful. It lets you reorganize the same Jira history by project, sprint, work type, priority, assignee, parent, story points, and other Jira fields—without losing the ability to drill down to individual work items.

The data stays the same. The angle changes.

A regular report and a pivot answer different questions

A regular Time in Status report gives you a close-up view.

Each row represents a work item, and each status column shows how long that item remained there. It is the right view when you need to investigate a particular ticket:

• Why did this bug take so long?
• How much time did this story spend in review?
• Where did this task wait before release?
• What happened during this work item’s lifecycle?

Think of it as an itemized receipt. Every detail is present.

But imagine receiving 500 receipts and being asked, “Which category are we overspending on?” The information is technically there, but you still need to organize it before the answer becomes visible.

Pivot Mode provides that wider view. Instead of reading one work item after another, you can group and compare them:

• Project against project
• Sprint against sprint
• Bugs against stories
• High-priority work against normal-priority work
• Small work items against large ones
• Parent initiatives against their child tasks
• Assigned work across team members

The regular report helps you understand an individual case. The pivot helps you determine whether that case is isolated or part of a larger pattern. You usually need both.

What changes when you enable Pivot Mode?

Pivot Mode rebuilds the report around three simple choices:

Building block	What it controls	Example
Row groups	What you want to compare	Project, Sprint, Priority, Assignee, Parent
Column labels	How you want to split each group	Bugs, Stories, Tasks
Values	What you want to measure	Sum, Average, Median, Maximum, Minimum, Count

For example:

Project in rows + Work item type in columns + Median time in Testing as a value

This shows the typical Testing time for bugs, stories, and tasks in each project.

You can also create row hierarchies such as Parent → Work item key. Start with the parent-level summary, then expand it to investigate individual work items.

A simple rule to remember:

• Rows show what you are comparing.
• Columns show how the comparison is divided.
• Values show the result.

Keep Work item key as the final drill-down level. If it is your first and only row group, you have recreated the regular report—just wearing a fake moustache.

When should you use Pivot Mode?

Pivot Mode is especially useful when:

• Your report contains too many work items to scan manually.
• You want to compare projects, teams, sprints, or work types.
• A large average looks suspicious and you want to check for outliers.
• You need a management-level summary with the option to drill into details.
• You want to understand whether high accumulated time comes from slow work or simply more work.
• Different stakeholders need different views of the same Jira history.
• You are preparing for a retrospective, workflow review, or release-risk discussion.

It is less useful when you already know the exact work item you need to investigate. In that case, the regular detailed report will usually get you there faster.

Here are several practical questions Pivot Mode can help answer.

1. Which workflow stage is slowing down each project?

Two projects can have similar delivery times for completely different reasons.

One may move slowly through development but pass testing quickly. Another may finish development in a day and then sit in review waiting for attention.

To compare them, configure the pivot like this:

• Row group: Project
• Column label: Work item type
• Values: Median time in In Progress, On Review, Testing, and Ready for Release

Why use the median? Because it represents the typical work item more reliably than the average when a few extreme cases exist.

This view can reveal patterns such as:

• Bugs in Project A spend most of their time in Testing.
• Stories in Project B wait unusually long for review.
• Project C develops quickly but accumulates work before release.
• One project’s workflow is consistently slower across several stages.

That gives you a much better starting point than saying, “Project B feels slow.”

You can now ask a specific question: Why is the typical review time for stories in Project B twice as long as in the other projects?

That is a question a team can actually investigate.

2. Which work item is delaying a larger initiative?

A parent initiative may look slow, but the delay often comes from only one or two child work items.

Group the report like this:

• First row group: Parent
• Second row group: Work item key
• Values: Sum or median time in the relevant statuses

Start with the collapsed parent rows. This gives you an overview of which initiatives accumulated the most time.

Then expand a parent to inspect its individual work items.

This helps you distinguish between:

• An initiative where most child items move slowly
• An initiative delayed by one exceptional work item
• A parent containing many small items that naturally accumulate a large total
• A parent with only a few items but unusually long waiting times

Use Sum to understand the total accumulated workflow time. Use Median to understand what happened to a typical child item.

The distinction matters. A large initiative can have a high total simply because it contains more work. That does not automatically mean its workflow is unhealthy.

3. Does high-priority work actually move faster?

Most teams agree that high-priority work should move faster.

Jira, however, has no shortage of “high-priority” tickets peacefully enjoying their third week in a queue.

To check whether priority changes the actual flow of work, use:

• Row group: Priority
• Column label: Work item type
• Values: Median time in To Do, In Progress, On Review, and Testing

Now compare high-priority work with medium- and low-priority work.

You may discover that:

• High-priority items enter development faster but wait just as long in review.
• Urgent bugs move quickly while urgent stories do not.
• Every priority level has almost identical status durations.
• High-priority work is actually slower because it tends to involve more complex incidents.

If the results are similar across priority levels, your priority field may be describing importance without changing team behavior.

That is not necessarily a reporting problem. It may be a workflow-policy problem.

A useful follow-up question is: What is supposed to happen differently when an item becomes high priority?

If nobody can answer that clearly, the red priority icon may be doing most of the work.

4. Do larger work items really take longer?

Story points are not hours. Everyone knows this.

They still appear in almost every conversation about delivery time, usually within five minutes.

Pivot Mode lets you examine the relationship without pretending that story points are a clock.

Configure the report with:

• Row group: Story Points
• Column label: Work item type
• Values: Median time in key workflow statuses

This can show whether larger work items:

• Spend longer in active development
• Wait longer for review
• Require significantly more testing
• Accumulate time before development even begins

The result can challenge easy assumptions.

A 13-point story may not spend much longer In Progress than a 5-point story—but it might wait much longer in review because the change is harder to understand.

You may also discover that very small items spend nearly as long waiting as large ones. In that case, the delay is probably caused by queues, handoffs, or scheduling rather than complexity.

Story points explain the size of the work. Pivoted status times help show how your system handles that size.

5. Is a workflow stage slow—or simply busy?

Imagine that Testing has accumulated 900 hours.

That sounds alarming. It may even deserve a dramatic red slide in the next review meeting.

But the total alone does not tell you why it is high.

Testing may have processed a large number of work items at a perfectly normal speed. Alternatively, a small number of items may each have waited far too long.

To separate volume from delay, use:

• Row group: Project, Team, or Sprint
• Column label: Work item type
• Values: Sum, Count, and Median for Testing or Review

Interpret the combination:

• High Sum + high Count + normal Median usually means high work volume.
• High Sum + normal Count + high Median suggests a genuinely slow stage.
• Normal Median + very high Maximum points to an exceptional work item.
• High Median across several groups suggests a recurring workflow problem.

This is one of the most useful pivot analyses because it prevents a common mistake: treating “a lot of accumulated time” as proof that every item is moving slowly.

Sometimes the queue is blocked. Sometimes the team simply processed a small mountain of work.

6. Where is the release risk hiding?

Release risk rarely arrives with a helpful label saying, “Hello, I will delay production next Thursday.”

It usually hides inside a parent initiative, version, label, or work item that has spent much longer than expected in Testing or Ready for Release.

A useful release-risk pivot could use:

• Row groups: Fix Version, Label, or Parent → Work item key
• Column label: Priority
• Values: Median and Maximum time in Testing and Ready for Release

Begin with the grouped summary, then expand the areas with unusually high values.

This can help identify:

• Versions containing multiple items stuck before release
• High-priority items waiting longer than normal
• One extreme work item hiding inside an otherwise healthy release
• Parents whose child items repeatedly stall at the same stage

The maximum is particularly useful here. The median tells you what is typical; the maximum tells you where to look first.

Not every old work item is a release risk, of course. Some are abandoned experiments, duplicates, or tickets everyone has silently agreed not to mention. The pivot finds the candidates. The team still provides the context.

Choosing the right calculation

The pivot layout determines how the data is grouped. The calculation determines what the result tells you.

Calculation	What it shows	Best used for	Keep in mind
Sum	Total accumulated time	Measuring overall workflow load	Groups with more work items naturally produce higher totals
Average	Mean duration across all items	Understanding overall performance, including extremes	A few unusually slow items can distort the result
Median	Duration of a typical work item	Comparing projects, sprints, priorities, and work types	May hide a small number of serious delays
Maximum	Longest recorded duration	Finding risks, neglected tickets, and outliers	One extreme item does not always indicate a recurring problem
Minimum	Fastest recorded duration	Establishing a best-case reference	An unusually low value may be an exception or data issue—not a realistic target
Count	Number of contributing work items	Adding volume context to other calculations	Count measures workload volume, not processing speed

Quick rule: Use Median for typical performance, Maximum for risk, Sum for total load, and Count to give every result context.

Calculation combinations that tell a better story

Single numbers can be persuasive. Pairs of numbers are usually more honest.

Use Average and Median to see whether extreme work items are pulling the average upward.

Use Median and Maximum to distinguish a recurring workflow problem from a few isolated delays.

Use Sum and Count to determine whether high accumulated time comes from slow processing or a larger volume of work.

For the clearest picture, use Count, Median, and Maximum together:

• Count gives you scale.
• Median gives you the typical experience.
• Maximum points to the first item worth investigating.

Start with one uncomfortable question

Do not begin by adding every Jira field to a pivot and hoping wisdom appears.

Start with a real question:

• Which project is waiting longest for review?
• Are urgent bugs moving faster than normal bugs?
• Is one work item delaying an entire initiative?
• Does Testing have a speed problem or a volume problem?
• Are larger stories slow in development or only in review?
• Where is our next release risk hiding?

Open the regular Time in Status report to see the detailed history. Then enable Pivot Mode when the next question requires comparison, grouping, or context.

The regular report tells you where the time went.

The pivot helps you understand whether it keeps going there—and what you should investigate next.

If your current reporting process involves exporting Jira data, rebuilding the same spreadsheet every week, and carefully avoiding the cell someone filled with bright yellow formatting in 2022, you can explore these views with a free trial of Time in Status by SaaSJet.

Bring one workflow question with you. That is usually enough to get started.