Your Jira Cycle Time report says 14 days.
But that number alone does not explain where work actually slowed down.
Was most of that time spent in Code Review? QA? Waiting for Customer? Ready to Deploy? Or in a status nobody on the team was even watching?
That is the problem with looking only at total Cycle Time. It tells you how long work took overall, but it does not show how that time was distributed across your workflow.
To improve delivery, teams need a Jira Cycle Time breakdown by status — a way to see which workflow stages consume the most time and which work items are driving those delays.
Why Jira Cycle Time Alone Is Not Enough
Cycle Time is useful because it shows how long it takes work to move through your process.
But Cycle Time is a sum, not an answer.
A 14-day Cycle Time could mean:
- 9 days in Code Review
- 6 days in QA
- 5 days waiting for customer feedback
- 4 days in Ready to Deploy
- or one large outlier ticket inflating the average
Without a status-level breakdown, the team sees the outcome but not the cause.
That makes improvement conversations too broad. “We need to reduce Cycle Time” is not a clear action plan. But “Code Review accounts for 42% of our Cycle Time, and these tickets stayed there the longest” gives the team something specific to investigate.
That is the difference between tracking a metric and using a metric to improve the workflow.
What Jira Reports Don’t Show by Default
Jira gives teams several useful reports, such as velocity charts, burndown charts, and control charts. These reports help teams understand delivery progress, sprint performance, and overall flow.
But they do not always answer one of the most practical questions:
Which Jira status is taking the largest share of our Cycle Time or Lead Time?
For many teams, this leads to manual analysis. They export Jira data, build spreadsheets, calculate time in each status, and try to understand where work is getting stuck.
That approach takes time every sprint or reporting period. It also disconnects the analysis from the actual Jira work items behind the delay.
A better approach is to analyze time distribution directly on a Jira dashboard — using the same workflow data already stored in Jira.
How to Break Down Jira Cycle Time by Status
A Cycle Time breakdown by status shows how much of your total tracked time is spent in each workflow stage.
For example, instead of seeing only this:
Average Cycle Time: 14 days
You can see something like this:
- Code Review — 42%
- QA — 31%
- Ready to Deploy — 14%
- In Progress — 9%
- Blocked — 4%
This instantly changes the conversation.
The team no longer has to guess where delays happen. They can see which status contributes most to the selected time metric and then drill down into the work items behind that number.
This is especially useful when analyzing:
- Cycle Time
- Lead Time
- Resolution Time
- Time in Status
- QA or Validation Time
- Code Review Time
- Waiting Time
- Approval Time
- any custom Jira time metric configured for your workflow
Total Time vs Average Time: Why Both Matter
When analyzing time spent in Jira statuses, it is important to understand the difference between Total time and Average time.
Total time shows the team-wide impact. It helps you understand where the most cumulative time is spent across all work items.
Average time shows the typical per-item experience. It helps you understand how long a usual ticket spends in a specific status.
Both views are useful, but they answer different questions.
A status with high Total time may not always mean every ticket is slow there. It could mean that a few large or unusual work items spent a very long time in that status.
A status with high Average time may indicate that most tickets experience delay there, even if the total volume is not the highest.
That is why switching between Total and Average views helps teams separate real workflow patterns from outliers.
When the Top Status Is Not Always the Real Bottleneck
When one status clearly takes the largest share of time, it is tempting to call it a bottleneck immediately.
But high time in one status can mean different things.
1. A real capacity constraint
This happens when work piles up because the team does not have enough capacity at a certain stage.
For example:
- not enough reviewers
- limited QA availability
- a shared testing environment
- delayed approvals
- external dependencies
In this case, the status is likely a real bottleneck.
2. A designed waiting state
Some statuses are expected to accumulate time.
For example, in support workflows, Waiting for Customer may naturally take a large share of Resolution Time. In approval workflows, Waiting for Approval may be an intentional queue.
High time in these statuses does not always mean something is broken. But it still helps teams understand how much of the overall process depends on waiting.
3. A misconfigured metric
Sometimes a status appears near the top because the time metric includes statuses that should not be part of the calculation.
For example, if On Hold, Cancelled, or Backlog statuses are included in a Cycle Time metric by mistake, the report may show inflated numbers.
This is why it is important not only to look at the chart, but also to check the work items behind the number.
How Different Teams Use Jira Status Contribution Analysis
Engineering Managers
Engineering managers can use a Cycle Time breakdown to understand whether delays are happening in development, Code Review, QA, or release preparation.
Instead of asking the team to self-report where work gets stuck, they can open a Jira dashboard and see which status contributes the most to delivery time.
For example:
Code Review: 42%
QA: 31%
Ready to Deploy: 14%
Now the team knows where to focus the next workflow discussion.
Delivery Managers
Delivery managers can use status contribution data to identify delivery risks before they become missed deadlines.
If one status takes 60% of the total Cycle Time, that is a strong signal that the team should investigate what is happening there.
It may point to a queue, a dependency, unclear ownership, or a stage that needs a WIP limit.
JSM and Support Teams
For Jira Service Management teams, the same approach can help break down Resolution Time.
For example, support teams can see whether time is mostly spent in:
- Investigation
- Waiting for Customer
- Escalated
- Waiting for Development
- Pending Approval
Each of these situations requires a different response.
If time is lost in Investigation, the team may need more technical capacity or better knowledge base coverage. If time accumulates in Waiting for Customer, the issue may be related to communication rules, SLA design, or follow-up processes.
Agile Coaches
Agile coaches can use a status-level breakdown to make retrospectives more specific.
Instead of opening the discussion with general impressions like “tickets are taking too long,” they can bring a ranked view of workflow stages and the exact work items that spent the most time there.
This helps the team move from opinions to evidence.
How the Status Contribution Chart Works
The Status Contribution Chart is a Jira dashboard gadget inside Time Metrics Tracker | Time Between Statuses.
It takes a selected time metric — such as Cycle Time, Lead Time, Resolution Time, or any custom time metric — and shows how time is distributed across the statuses included in that metric.
With the gadget, teams can see:
- a ranked list of statuses by time contribution
- percentage and time value for each status
- Total and Average views
- the top status at a glance
- the number of work items included in the calculation
- a drill-down modal with the specific Jira issues behind each status
The main value is simple: you do not need to export Jira data or build a spreadsheet to understand where time is going.
You can analyze workflow delays directly from your Jira dashboard.
How to Read the Status Contribution Chart
Scenario 1: One status dominates the chart
If one status takes 60–70% or more of the tracked time, this is the clearest signal to investigate.
But do not assume immediately that the status is a bottleneck.
First, open the drill-down and check the actual work items.
Look for patterns:
- Are the same issue types always delayed there?
- Are tickets waiting for the same person or team?
- Is this a real queue or an expected waiting state?
- Are there outlier tickets that distort the result?
- Should this status be included in the selected time metric?
Once you know the pattern, the team can decide what to change.
Scenario 2: Time is spread evenly across statuses
If time is distributed relatively evenly, there may not be one obvious bottleneck.
In this case, switch from Total time to Average time.
Average time can show which status adds the most delay to a typical work item. That is often where a process improvement, WIP limit, or clearer ownership can help.
Scenario 3: An unexpected status appears near the top
Sometimes the most useful insight is not the biggest status, but the unexpected one.
A status like Blocked, Waiting for Merge, Ready for QA, or In Refinement may quietly accumulate more time than the team realizes.
These hidden waiting states are easy to miss in daily work, especially when everyone focuses only on active development.
The chart makes them visible.
Practical Ways to Act on the Data
Once you know which status contributes the most time, the next step is to decide what action makes sense.
Here are a few examples.
If Code Review takes the largest share of Cycle Time, you may need to review reviewer availability, set review expectations, reduce batch size, or make review ownership clearer.
If QA or Validation dominates the chart, the team may need to move testing earlier, split large work items, improve acceptance criteria, or avoid sending too much work into QA at the end of a sprint.
If Waiting for Customer takes the most time in a support workflow, the team may need better follow-up rules, clearer SLA expectations, or improved customer communication templates.
If Ready to Deploy keeps growing, the issue may be release coordination, deployment frequency, approval flow, or environment availability.
The point is not just to find the biggest number.
The point is to understand what kind of delay it represents.
From Jira Metrics to Workflow Decisions
Cycle Time is a useful starting point.
But a number without a breakdown is still just a number.
To improve delivery, teams need to know where that time is actually spent, which statuses contribute most to the delay, and which Jira issues are behind the pattern.
That is what turns Cycle Time from a reporting metric into a workflow improvement tool.
With the Status Contribution Chart in Time Metrics Tracker | Time Between Statuses, teams can break down Jira Cycle Time, Lead Time, Resolution Time, or any custom time metric by status — directly on a Jira dashboard.
No manual exports.
No spreadsheet reconstruction.
No guessing where work gets stuck.
Just a clear view of how time moves through your Jira workflow.
FAQ
What is a Jira Cycle Time breakdown?
A Jira Cycle Time breakdown shows how total Cycle Time is distributed across workflow statuses. Instead of seeing only the total number of days, teams can understand how much time was spent in Code Review, QA, Waiting for Customer, Ready to Deploy, or any other status included in the metric.
How can I see time spent in each Jira status?
Jira doesn’t calculate time in status natively — it stores transition history, but doesn’t surface how long a work item spent in each stage.
To get that breakdown, you need an app that reads transition logs and turns them into readable time data. In Time Metrics Tracker, this works directly from your Jira Dashboard: choose a project or board, select a time metric, and the Status Contribution Chart shows you exactly which statuses take the largest share — with a drill-down to the specific tickets behind each number.
What is the difference between Total time and Average time?
Total time shows the cumulative time spent in a status across all work items. Average time shows the typical time one work item spends in that status. Total time helps identify team-wide impact, while Average time helps understand the usual per-ticket experience.
How do I find bottlenecks in a Jira workflow?
Look for statuses that consistently take the largest share of Cycle Time, Lead Time, or Resolution Time. Then review the work items behind those statuses to understand whether the delay comes from capacity limits, waiting states, dependencies, outliers, or metric configuration.
Can I analyze custom Jira time metrics by status?
Yes. With Time Metrics Tracker, teams can configure custom time metrics based on their workflow and analyze how time is distributed across the statuses included in those metrics. This can be used for Cycle Time, Lead Time, QA Time, Code Review Time, Approval Time, Waiting Time, Resolution Time, and other workflow-specific metrics.
