Time in Status in Jira: How to Find Workflow Bottlenecks Before They Slow Down Your Team

[#1]

Every Jira team has experienced this moment.

As a sprint ends and deadlines approach, several issues often remain in stages such as In Progress, Code Review, or Waiting for Approval. Despite the team's efforts, delivery may still be slower than anticipated.

This raises a key question: Where is the time actually going?

This is where tracking time in status in Jira becomes a valuable workflow metric.

Delays rarely occur all at once; instead, they accumulate gradually:

• in review queues,
• approval stages,
• customer waiting periods,
• handoffs between teams,
• or issues bouncing back and forth across statuses.

Although Jira automatically records workflow history, many teams struggle to convert this data into actionable operational insights.

This article explores:

• what Jira time in status really means,
• why teams rely on it to improve delivery,
• how to track Jira time spent in status,
• and how tools like Time in Status by SaaSJet help transform Jira workflow history into actionable reporting.

What Is Time in Status in Jira?

Time in status measures how long an issue spends in each workflow stage during its lifecycle.

For example:

Status	Time Spent
To Do	1 day
In Progress	3 days
Code Review	2 days
QA Testing	4 days

At first glance, it may seem like a simple metric.

But once teams begin analyzing status timing across projects, patterns start appearing very quickly.

You can suddenly see:

• where work gets stuck,
• which approvals create delays,
• how long reviews actually take,
• whether tickets spend more time waiting than being worked on,
• and why delivery becomes unpredictable.

For this reason, more organizations track time in status in Jira instead of relying only on sprint velocity or issue counts.

Completed work shows what happened, while workflow timing explains why it happened.

Why Jira Teams Struggle to Identify Bottlenecks

Most teams sense that something is slowing them down, but proving it is often challenging.

A development team may assume engineering is overloaded — until they discover issues spend most of their lifecycle waiting for QA review.

A support manager may think agents are missing SLAs — until workflow analysis reveals tickets sit in Waiting for Customer for days at a time.

A product team may blame prioritization problems, while ideas are actually stuck in review and approval stages.

Without visibility into Jira time in status, these delays remain hidden inside workflows.

And that usually leads to:

• more meetings,
• manual spreadsheets,
• status chasing,
• complicated JQL filters,
• and endless assumptions.

Native Jira Reporting Has Limits

Jira already records:

• status changes,
• assignee updates,
• sprint movement,
• transition history,
• and resolution timestamps.

However, native reporting does not always make this information easy to analyze.

Teams eventually start asking questions like:

• What’s our Jira average time in status?
• Which workflow stage creates the most delay?
• How many times do issues reopen?
• Can we automatically count issue status transitions?
• How do we identify aging work?
• Is there a way to separate waiting time from active work?
• How can we export Jira data for deeper analysis?

And this is usually the point where native Jira dashboards stop being enough.

The Real Problem Isn’t Work — It’s Waiting

One of the biggest discoveries teams make after analyzing workflow timing is this:

Most delays are not caused by actual work.

They’re caused by waiting.

Waiting for:

• approvals,
• customers,
• reviewers,
• deployments,
• vendors,
• or handoffs between departments.

This distinction matters because not all time should be treated equally. For example:

• A support ticket awaiting customer feedback should not count against agent productivity,
• Similarly, a development issue blocked in QA should not inflate engineering cycle time.

That’s why mature teams increasingly separate:

• Working statuses
  from
• Waiting statuses

when building a Time in Status Jira dashboard.

Turning Jira Workflow History Into Useful Insights

This is exactly where specialized workflow analytics tools become valuable.

Instead of manually piecing together reports from Jira exports, teams can use tools like Time in Status by SaaSJet to automatically transform workflow history into:

• time in status reports,
• cycle and lead time analysis,
• status transition tracking,
• sprint analytics,
• dashboards,
• charts,
• and exportable datasets.

The goal is not simply to generate more reports. It is to make workflow behavior visible enough to enable improvement.

How Engineering Teams Use Jira Time in Status

Engineering teams often start with a simple question:

“Why does delivery feel slower than expected?”

Once they begin analyzing Jira time spent in status, they usually uncover patterns such as:

• long review queues,
• QA bottlenecks,
• excessive reopen loops,
• or issues waiting too long for approvals.

One engineering workflow analysis found that teams reduced cycle time by 25% after identifying delays at development-to-QA handoffs.

This kind of visibility helps teams:

• reduce lead time,
• stabilize sprint delivery,
• improve throughput,
• and eliminate workflow friction.

Some teams also monitor the number of transitions Jira issues go through to identify excessive “ping-pong” between statuses.

If a task moves between QA and Development six times, the issue is usually not speed but process quality.

Support Teams Need Visibility Into Waiting Time

Support organizations face a different challenge.

A ticket may technically remain open for several days, but agents may spend only a small fraction of that time actively working on it.

The rest may be spent:

• waiting for customer replies,
• vendor updates,
• escalations,
• or approvals.

Without separating those states, SLA reporting becomes misleading.

That’s why many support teams use Jira time in status reporting to distinguish:

• active handling time,
• customer waiting time,
• and blocked workflow stages.

One IT support team reduced SLA breaches by 45% after separating working and waiting statuses inside their workflow reporting. 

Product Teams Use Workflow Timing to Reduce Decision Delays

Product organizations often experience a different kind of bottleneck:
ideas that quietly stagnate.

Features remain in:

• Review,
• Discovery,
• Validation,
• or Approval

for weeks without the delay being clearly identified.

By measuring Jira average time in status across review stages, product teams can:

• identify aging ideas,
• compare decision speed across squads,
• reduce prioritization delays,
• and improve roadmap predictability.

One product team improved decision-making speed by 40% after analyzing workflow timing between discovery and validation stages.

Why Jira Pivot Reports Become Important as Teams Grow

At first, simple reports are enough.

But as organizations scale, workflow analysis becomes more complex.

Teams eventually need to:

• compare projects,
• analyze departments,
• aggregate statuses,
• monitor trends,
• or evaluate workload distribution across multiple squads.

That’s where a Jira pivot report becomes especially useful.

Instead of reviewing issues individually, teams can analyze:

• average status duration,
• assignee workload,
• transition counts,
• throughput trends,
• and bottlenecks

inside a single analytical view.

This becomes particularly valuable for:

• PMOs,
• enterprise operations,
• portfolio reporting,
• and leadership dashboards.

 

Report Summary and Status Summary: Turning Workflow Data Into Clear Insights

As Jira reporting grows more advanced, teams often need a way to summarize workflow behavior without drowning in details.

This is where the Report Summary / Status Summary functionality in Time in Status by SaaSJet becomes especially valuable.

Instead of analyzing every individual status separately, teams can group workflow stages into broader operational categories such as:

• Working,
• Waiting,
• Review,
• Approval,
• Blocked,
• or Done.

This creates a much cleaner high-level picture of how work actually flows.

For example, instead of reviewing:

• Code Review,
• QA Testing,
• Ready for QA,
• UAT,

separately, teams can summarize them into a single:

“Review & Validation”

group.

The same applies to:

• customer waiting,
• vendor delays,
• approvals,
• or blocked work.

This approach helps teams quickly understand:

• where the majority of workflow time accumulates,
• whether delays are operational or external,
• and which parts of the process need attention first.

It also makes executive reporting significantly easier because dashboards become easier to interpret without losing analytical depth.

Instead of overwhelming stakeholders with workflow complexity, teams can focus conversations on:

• delivery flow,
• bottlenecks,
• waiting time,
• and process efficiency.

 

Column Groups in Table View: Making Large Jira Reports Manageable

As reporting matures across multiple teams and projects, another challenge appears:
reports become too wide to read comfortably.

This is especially common when organizations track:

• many workflow statuses,
• multiple assignees,
• several time metrics,
• transition counts,
• custom calculations,
• or status groups inside one report.

The Column Groups in Table View feature in Time in Status helps solve this by organizing related columns into structured groups.

Instead of showing dozens of disconnected metrics, teams can logically organize data into sections like:

• Time Metrics,
• Status Groups,
• Assignee Metrics,
• Sprint Analytics,
• Transition Data,
• or SLA Indicators.

This makes large Jira reports dramatically easier to navigate.

For example:
a support manager may want to focus only on:

• waiting time,
• SLA-related statuses,
• and escalation metrics,

while an engineering lead may care more about:

• review duration,
• cycle time,
• and reopen counts.

Column grouping allows both teams to work with the same dataset while focusing only on the metrics relevant to them.

This becomes especially useful in:

• enterprise reporting,
• PMO dashboards,
• operational reviews,
• and cross-team workflow analysis.

Because as Jira reporting grows, clarity becomes just as important as detail.

And often, the teams that improve delivery the fastest are not the ones collecting the most metrics — but the ones presenting workflow insights in a way people can actually understand and act on.

Jira Time in Status JQL and Automation

As workflows become more complex, teams usually outgrow static reports.

At some point, managers no longer want to manually open dashboards every morning just to check whether issues are stuck. They want Jira itself to surface risks automatically:

• tickets sitting too long in review,
• aging approvals,
• blocked tasks,
• or requests approaching SLA breaches.

This is where Time in Status custom fields become especially powerful.

Instead of storing workflow timing only inside reports, Time in Status by SaaSJet allows teams to create custom fields that display live status timing directly inside Jira issues, boards, queues, and filters.

For example, teams can create custom fields for:

• current time in status,
• cycle time,
• lead time,
• working time,
• waiting time,
• or time spent in specific workflow stages.

The biggest advantage is that these fields are fully usable across Jira — not just within the app.

That means teams can:

• display timing directly on issue cards,
• add status timing to dashboards,
• build Jira automations,
• create alerts,
• and use Jira time in status JQL queries for proactive workflow management.

For example, teams can automatically identify:

• issues staying in Code Review longer than expected,
• tickets waiting on approvals for several days,
• stale support requests,
• or tasks that exceeded internal workflow thresholds.

Instead of reacting to delays after they happen, teams can proactively detect bottlenecks while work is still in progress.

This becomes especially valuable for:

• SLA monitoring,
• aging issue management,
• Kanban workflows,
• support escalation,
• and operational triage.

Many teams also add these custom fields directly to their Jira board card layout, making workflow delays visible without opening reports at all.

So rather than constantly asking:

“Which tickets are stuck?”

The answer becomes immediately visible inside Jira itself.

And for Jira Enterprise Plan users, the good news is that the “time in status” custom field is part of the Atlassian Data Lake, and you can use it to create informative charts and reports for Atlassian Analytics.

 

Why More Teams Build Dedicated Time in Status Jira Dashboards

Modern Jira teams want visibility without opening 10 different reports.

That’s why dashboards have become central to workflow management.

A well-designed Time in Status Jira dashboard can instantly show:

• aging issues,
• blocked tasks,
• review bottlenecks,
• transition trends,
• workload imbalance,
• and SLA risk areas.

More importantly, dashboards create alignment.

Instead of debating assumptions in meetings, teams work from the same operational picture.

Jira Sprint Reports Tell You What Happened — Not Always Why

Traditional Jira sprint reports are great for tracking:

• velocity,
• completion rate,
• burndown,
• and scope change.

But they often miss the deeper workflow story behind sprint performance.

For example:

• Why did carryover suddenly increase this sprint?
• Why did QA become overloaded right before release?
• Which workflow stage slowed delivery the most?
• Why are issues spending longer in review than they did last month?
• Are blockers caused by workload, waiting time, or scope changes?

Standard sprint metrics can indicate that something changed, but do not always reveal the cause.

That’s why many teams combine sprint analytics with Jira time in status reporting to understand how work actually moved during the sprint.

Instead of looking only at completed issues, they start analyzing:

• time spent in workflow stages,
• blocked work,
• workload distribution,
• flagged issues,
• and scope movement throughout the sprint lifecycle.

This is where the Sprint Report in Time in Status by SaaSJet becomes especially useful.

Rather than serving as a simple sprint summary, it provides a much more complete view of sprint health, combining visual charts, operational metrics, and workflow timing analysis in one place.

Teams can analyze sprint performance based on:

• Story Points,
• Work Item Count,
• or Original Time estimates,

depending on how their Jira boards are configured.

This flexibility is important because every team estimates differently. Some teams focus on story points, while others rely on issue count or original time estimates for forecasting and workload planning.

Another major advantage is support for both:

• completed sprints,
• and active sprints.

For active sprints, the report dynamically updates metrics in real time, allowing teams to monitor:

• current progress,
• burndown trends,
• workload distribution,
• scope changes,
• completed work,
• and status timing while the sprint is still running.

Instead of waiting until the retrospective, teams can identify problems early:

• overloaded workflow stages,
• growing review queues,
• excessive blocked work,
• or delivery slowdown before sprint completion.

The report also helps teams drill deeper into sprint metrics using interactive data tables.

Rather than seeing only a single number on a chart, teams can open detailed metric tables to understand:

• which issues contributed to carryover,
• what affected completion rates,
• which tasks increased sprint scope,
• or how estimation totals were calculated.

This makes retrospectives more actionable, as teams can connect sprint outcomes to actual workflow behavior rather than relying on assumptions.

For example, a sprint may appear slower than usual, not because developers completed less work, but because issues spent significantly longer in QA review or approval stages.

This distinction fundamentally changes the conversation.

Rather than attributing issues to productivity, teams can focus on addressing the actual workflow bottleneck.

In practice, this helps Scrum teams:

• improve sprint predictability,
• reduce carryover,
• detect workflow imbalance earlier,
• and make retrospectives more evidence-based rather than opinion-based.

Because the most valuable sprint insight is rarely:

“How much work did we finish?”

It’s usually:

“What slowed work down — and how do we improve it next sprint?”

Reporting Shouldn’t Depend on Spreadsheets

One of the biggest operational problems growing teams face is reporting fragmentation.

Different teams export Jira data into:

• spreadsheets,
• slide decks,
• BI tools,
• or manually maintained reports.

Eventually, nobody trusts the numbers because every report calculates metrics differently.

This is another reason workflow analytics platforms have become so important.

Teams can:

• save report presets,
• standardize status groups,
• share Jira reports across departments,
• and export Jira data into tools like Power BI or Google Sheets without rebuilding reports from scratch every month.

The Most Valuable Insight Teams Discover

The most significant realization is usually not about productivity, but about flow.

High-performing teams are not always those working the fastest.

They are the teams where work moves predictably:

• with fewer handoff delays,
• fewer reopen loops,
• less waiting time,
• and better operational visibility.

That’s why tracking Jira time spent in status has become such an important workflow practice across engineering, ITSM, HR, product, operations, and support teams.

Once teams can clearly see where time accumulates, improving delivery becomes significantly easier.

Final Thoughts

Jira already contains your organization's operational history.

Every workflow transition, every approval delay, every bottleneck, and every blocked task is already there.

The challenge is to make that history accessible and understandable.

That’s why more teams are investing in workflow visibility through:

• Jira time in status reports,
• dashboards,
• transition analytics,
• sprint reporting,
• and workflow timing analysis.

Tools like Time in Status by SaaSJet help bridge this gap by transforming raw Jira workflow history into clear operational insights that teams can act on.

This is achieved not by changing how teams work, but by enabling them to see how work truly flows.

Helpful Resources

📘 Time in Status Documentation

🚀 Time in Status for Jira

• Jira Cloud
• Jira Data Center