When One Jira Report Isn’t Enough: Meet the New Pivot Mode

[#1]

Every Jira team has experienced this moment. You open a Jira report containing several thousand work items.

The data is there. Projects, statuses, assignees, issue types, fix versions, sprints. But the real question was never about one issue. It's about patterns.

Are bugs in Project A spending more time in QA than stories in Project B? Which fix version has accumulated the highest waiting time? Which assignees show the highest average time in review? Where does cycle time increase when issue type, status, and project all interact at once? 

A flat table can answer some of these questions — with enough scrolling, exporting, and manual cross-referencing. But at enterprise scale, "enough" scrolling turns into hours, and hours turn into a spreadsheet nobody trusts anymore. 

That is the gap the new Pivot Mode in Time in Status app by SaaSJet is designed to address. 

Why Enterprise Workflow Analysis Needs More Than One Dimension 

For a smaller Jira instance, looking at one field at a time may be enough. You can filter by issue type, assignee, sprint, or project. Then you review the results and identify unusually long durations.

Enterprise environments are different.

A Jira admin may be responsible for dozens of projects. A PMO may need to compare delivery patterns across departments. An engineering manager may need to understand whether bugs, stories, and service requests behave differently across several workflows.

The useful questions become combinations:

• Issue Type + Status
• Project + Assignee
• Fix Version + Status
• Sprint + Issue Type
• Project + Status + Average Time

At that point, the question is no longer "how long did issues stay in In Progress?" It becomes "which issue types, in which projects, for which fix versions, are spending the most time in In Progress?" 

That's a different level of analysis. 

What Changes with the New Pivot Mode 

The new Pivot Mode is designed to support deeper workflow analysis and larger datasets directly inside the report's Table view.

It can be enabled from the Columns panel, with field selection handled in a side panel.

Fields can be dragged into:

• Row groups — categories to group by, such as Assignee or Project.
• Column labels — categories to compare side-by-side, such as Status.
• Values, aggregated as Sum, Min, Max, Count, Average, or Median depending on field type.

The grid updates with every change, so comparisons across dimensions are immediate rather than requiring a new report. 

The new Pivot Mode helps users analyze Jira workflow performance from multiple angles without leaving Time in Status or exporting data into spreadsheets. 

Practical Examples of Pivot Analysis 

Example 1: Analyze Average Time by Issue Type and Status

Question: Which issue types spend the longest in each workflow status? 

Use case: A team groups rows by Issue Type and pivots by Status. This helps compare bugs, stories, tasks, and epics across the workflow.

How to configure:

1. Set the report scope to by: JQL or Filter.
2. Open the Time in Status report, switch to Table view, and enable Pivot Mode from the Columns panel.
3. In the side panel, drag Type into Row groups.
4. Expand Statuses and drag the statuses you want to compare — e.g. In Progress and On review — into Values.
5. For each one, set the aggregation to Average. 

Insight: Bugs may move quickly through development but spend longer in QA. Features may spend more time in review. Tasks may get stuck in waiting statuses.

Example 2: Compare Workflow Performance by Project 

Question: Which projects have the longest average cycle time? 

Use case: A Jira admin groups the report by Project and compares the average or median Cycle Time across projects. 

How to configure:

1. Set the report scope to by: JQL with a query covering multiple projects (e.g. project in (A, B, C)) — this is what puts more than one project into the dataset in the first place. 
2. In Table view, go to Columns → Jira fields and add the Project field, plus Columns → Status Groups and add a Cycle Time group (or confirm one already exists) if it isn't already in the report.
3. Enable Pivot Mode from the Columns panel.
4. Drag Project into Row groups. Optional: drag Work item key into Row groups underneath Project if you want to expand a project and see Cycle Time per individual issue, rather than just the project-level average. 
5. Drag Cycle Time into Values, and set the aggregation to Average (or Median).

 

Insight: One project may carry a longer cycle time simply because more of its work sits in active statuses longer — not because the team is slower, but because the process itself has more steps or handoffs. 

Example 3: Analyze Fix Version Delays 

Question:  Which release accumulated the most waiting time?

Use case: A release manager groups by Fix Version and pivots by Status.

How to configure:

1. Set the report scope to by: Project and select the project whose releases you want to compare (use by: JQL instead if you need Fix Versions spanning multiple projects).
2. In Table view, go to Columns → Jira fields and add Fix versions if it isn't already showing in the report.
3. Enable Pivot Mode from the Columns panel.
4. Drag Fix versions into Row groups.
5. Drag the waiting/blocked statuses into Values — e.g. On review, Ready for Testing.
6. Set each to Sum — this example asks for accumulated time, not an average per issue.

 

Insight: A delayed release may not be slow because of development. It may be slow because issues spend too much time in QA, approval, or blocked statuses. 

Example 4: Understand Assignee Workload Patterns 

Question: Are delays concentrated around specific assignees or roles?

Use Case: A team lead groups by Assignee and compares average time across statuses.

How to configure:

1. Set the report scope to by: JQL or Filter.
2. Enable Pivot Mode on the Time in Status report.
3. Drag Assignee into Row groups.
4. Drag the relevant statuses (e.g. In Progress, On review) into Values.
5. Set each to Average.

 

Insight: One person may appear overloaded because too many issues sit with them in review or testing. This can support better workload balancing.

Example 5: Combine Project, Issue Type, and Status 

Question: Which type of work causes delays in which project?

Use Case: Enterprise teams combine multiple dimensions to identify patterns that would be invisible in a flat report.

How to configure:

1. Set the report scope to by: JQL with a query covering the projects you want to compare (e.g. project in (A, B)) — this is what puts multiple projects into the dataset before any grouping happens.
2. Enable Pivot Mode on the Time in Status report.
3. Drag Project into Row groups, then drag Type underneath it in Row groups — this nests issue type inside each project.
4. Drag the relevant statuses (e.g. In Progress, On review) into Values.
5. Set each to Average (or Sum for total accumulated time per combination).
6. If you want a further breakdown — e.g. the same view split by Sprint — drag Sprint into Column labels.

 

Insight: The bottleneck is not simply “QA.” It may be “bugs in Project X during Release Y.”

Why This Matters for Enterprise Customers

Enterprise Jira environments rarely have a shortage of data. The real challenge is turning large, complex datasets into something teams can compare and act on.

When work is spread across multiple projects, teams, releases, and workflows, a simple issue list is no longer enough. Jira admins and reporting teams need to understand how performance differs across projects, issue types, statuses, assignees, and versions — without repeatedly exporting reports and rebuilding the same analysis in spreadsheets.

The new Pivot Mode supports this by providing:

• more capacity for larger reports;
• deeper analysis across several workflow dimensions;
• clearer comparisons between teams, projects, and work types;
• fewer manual exports and spreadsheet-based workarounds;
• more flexible analytics directly inside Jira.

The main value is not simply a larger table. It is the ability to move from:

“Here is a list of issues.”

to:

“Here is the pattern behind our workflow performance.”

That broader view helps Jira admins, PMO teams, engineering managers, delivery leads, and enterprise reporting teams make process decisions with more context and greater confidence.

Conclusion: From Reporting to Exploration

Flat reports remain useful when teams need to inspect individual work items and understand exactly what happened.

But improving enterprise workflows often requires a broader view. Teams need to compare projects, issue types, statuses, fix versions, assignees, and other Jira fields together. The goal is not only to see where time is spent, but to understand which combinations create delays and where patterns repeat.

The new Pivot Mode supports that shift from reviewing records to exploring relationships across workflow data.

It helps teams ask more precise questions, identify patterns faster, and make process decisions based on evidence rather than assumptions.

Start with one question from your own Jira data, build a simple pivot around it, and examine the work items behind the most unexpected result.

A report shows what happened. A pivot helps explain the pattern behind it.

---

Helpful Resources

• Time in Status for Jira Cloud
• Documentation