Cycle time vs lead time in Jira — what's the difference and how to measure them

“How fast do we ship?” is really two questions. Lead time is the whole span from when work is requested (the issue is created) to when it’s delivered — including the wait before anyone starts. Cycle time is the narrower span from when work actually starts (commonly In Progress) to done. Jira doesn’t report either cleanly: the Control Chart gives one cycle-time-style number per issue on one board, and there’s no native lead-time report at all. Here’s the distinction in practice, and how to get both numbers — plus the per-status breakdown underneath them.

Why the gap matters

The gap between the two clocks is the waiting. If lead time is two weeks but cycle time is two days, your problem isn’t the team’s speed — it’s the twelve days work sat before anyone started. That’s why you need both numbers: one tells you how the system is doing (queueing, prioritization, backlog health), the other how the work is doing once someone actually picks it up.

Why Jira struggles with both

• The Control Chart gives you a single cycle-time-style number per issue, on one board — useful, but it’s one aggregate figure and it doesn’t isolate lead time.
• There’s no clean native lead-time report. You’d reconstruct it by subtracting created-date from resolved-date by hand.
• Neither shows where the time went. Both, at best, give you a total. Neither breaks it down by the statuses where the work actually waited — which is the only view that tells you what to fix.

So natively you get, at most, one blurry number and a lot of manual date math — and never the per-stage picture.

Getting them from time in status

Both clocks are really just sums of how long an issue spent in each status. Add up every status from start to done and you have cycle time; add the waiting-before-start too and you have lead time. Measuring time in status gives you both — and, more importantly, the breakdown underneath them.

Linger reports how long issues spend in each status, so you can compute cycle and lead time from real per-stage durations and see exactly which stage is eating the flow time — instead of staring at one aggregate number.

Why the per-stage view wins:

• Both clocks, honestly — totals built from actual status durations, not two dates subtracted.
• Where, not just how long — the status that consumes the time is the bottleneck; that’s what you act on.
• Across many issues — spot the stage that’s slow as a pattern, not issue by issue.

This is the same reason a single Control Chart number isn’t enough on its own — see Jira’s Control Chart vs time in status for that comparison.

Which do you use?

• Reporting delivery speed to stakeholders? Lead time — request to delivery.
• Improving how fast the team moves once it starts? Cycle time — work-started to done.
• Trying to actually shorten either? Measure time in status, so you can see the stage that’s costing you and fix that — a tool like Linger gives you the breakdown the native reports don’t.