Cycle time tells you how long your team actually takes to do the work, once it has started. Where lead time captures the whole customer wait, cycle time zooms in on active development — which makes it one of the most actionable metrics for process improvement. This guide explains what cycle time is, how Flow Metrics Charts for Jira Cloud calculates it from your status history, how to read it, and how to bring it down.
What is cycle time?
Cycle time is the time a work item spends in active development — from the moment it enters an “in progress” status until it reaches “done”. It deliberately excludes time spent waiting in a backlog or queue before work begins, isolating the part of the process your team most directly controls. It is one half of the app’s Flow Time chart; the other half, lead time, adds back all the waiting.
How cycle time is calculated in Jira
Flow Metrics Charts measures cycle time only for completed issues, using the status transitions recorded in each issue’s changelog. You define which statuses count as “in progress” and which count as “done”, so the metric matches how your team really works. Issues that never had proper transitions are excluded rather than shown as zero, which keeps the data honest. Each period reports the minimum, average and maximum so you see the spread, not just a single figure.
Cycle time vs lead time
The two are often confused. Lead time is the full customer wait (created to delivered, including queues); cycle time is only the active working window. The gap between them is pure waiting. For the full comparison with a worked Jira example, see Cycle Time vs. Lead Time. Both feed into the broader DORA metrics framework — see DORA Metrics in Jira for all four keys and how they fit together.
How to read the cycle time chart
- Watch the trend over several sprints, not single issues. A rising line points to blockers, oversized items, or too much work in progress.
- Break it down by issue type or epic to find where the time goes — a single heavy category often drags the average.
- Use percentiles, not averages, to forecast: “85% of items finish within 6 active days” is far more reliable than a mean.
- Smaller, more uniform items produce shorter, more predictable cycle times.
Why cycle time matters for your business
Unlike total lead time, cycle time reflects choices your team can change this sprint, which makes it the most directly improvable speed metric. Long cycle times reveal blockers, handoffs, oversized items or excessive multitasking; short, predictable ones make delivery dates believable and feedback loops fast. It is the metric to watch when you want to prove a process change actually made the team quicker.
How to reduce cycle time
- Limit work in progress. By Little’s Law, cycle time is proportional to WIP at a given throughput — cutting WIP is the fastest lever.
- Find the waiting. Use time in status to see which stage (often code review or test) swallows the most time, then attack that handoff.
- Split large items so they flow through review and testing quickly.
- Configure start and end statuses carefully — include real active work such as review and testing, and exclude pure waiting states so the number reflects effort, not queues.
How cycle time connects to the other flow metrics
Cycle time sits at the centre of the flow-metrics system. It falls when you lower flow load, it feeds lead time, and steady cycle times are what produce high system stability and believable forecasts. Read alongside throughput, it tells you not just how much you deliver, but how quickly each item moves.
Track cycle time in Jira
Flow Metrics Charts for Jira Cloud calculates cycle time directly from your Jira status transitions — no spreadsheets or manual timing — on an interactive board and in dashboard gadgets, with Rovo AI highlighting where work is slowing down. For the practical walkthrough, see How to read the Flow Time chart, or start with the flow metrics for Jira overview.
Frequently asked questions
What is cycle time in Agile?
Cycle time is the time a work item spends in active development, from when a team starts it (it moves to an in-progress status) until it is done. It excludes time waiting in the backlog, so it measures working time rather than total wait.
How is cycle time calculated in Jira?
Flow Metrics Charts calculates cycle time from each completed issue’s status transitions — the elapsed time between your chosen start and end statuses — and reports minimum, average and maximum per period. Issues without proper transitions are excluded.
What is a good cycle time?
There is no universal target; a good cycle time is short and, above all, consistent. Track your 85th-percentile cycle time and aim to reduce it over time rather than comparing raw numbers with other teams.
1 Comment
Leave your reply.