"Cycle time" and "lead time" get used interchangeably in Agile retrospectives. They're not the same thing and using the wrong one to diagnose a delivery problem sends you in the wrong direction.
The practical difference, how to pull each from Jira, and when each one is actually worth tracking.
Lead time: total elapsed time from when a request enters your system to when it ships. In Jira: from issue creation to resolution.
Cycle time: time from when work actually starts to when it's done. In Jira: from the first transition to "In Progress" to "Done".
Everything that happens before work starts: backlog sitting time, prioritization, sprint planning counts in lead time but not cycle time.
Issue created ──────────────────────────────── Issue done
│ │ │
└──────── Lead time ─────────────────────────┘
│ │
└──── Cycle time ────────┘
(work started)
Why the distinction matters
They answer different questions.
Cycle time answers: how fast does your team execute once work begins? If your average is 3 days and it jumps to 7, something in your delivery process changed, PRs sitting in review longer, issues scoped too large, a recurring blocker type.
Lead time answers: what's the full wait from request to delivery, from the outside? A team can have tight cycle time (fast once they start) but a 3-week backlog before anything gets picked up. Customers experience lead time, not cycle time. Promising a delivery window without knowing your lead time is promising something you can't verify.
Getting these from Jira
Neither metric is surfaced cleanly by default.
Control Chart (closest native option)
Available under Reports on Kanban boards. It plots time-in-progress per issue, an approximation of cycle time if your "In Progress" column maps accurately to when work starts.
The catch: it measures time in board columns, not workflow statuses. If your board doesn't map 1:1 to your actual statuses, the numbers are blurred.
Jira project → Reports → Control Chart (Kanban boards only).
JQL for lead time
Jira doesn't expose timeInStatus as a JQL field, but lead time is straightforward once you export to CSV:
project = MYPROJECT AND status = Done AND resolved >= -30d ORDER BY resolved DESC
In the export: resolutiondate minus created = lead time. You can do this in a spreadsheet in about five minutes.
REST API for cycle time
Cycle time requires the status change history, which doesn't appear in the standard CSV export. You need the changelog:
const response = await fetch(
`${baseUrl}/rest/api/3/issue/${issueKey}?expand=changelog`,
{ headers: { Authorization: `Basic ${btoa(`${email}:${token}`)}` } }
);
const { changelog } = await response.json();
const inProgressTransition = changelog.histories
.flatMap(h => h.items.map(i => ({ ...i, created: h.created })))
.find(i => i.field === 'status' && i.toString === 'In Progress');
const doneTransition = changelog.histories
.flatMap(h => h.items.map(i => ({ ...i, created: h.created })))
.reverse()
.find(i => i.field === 'status' && i.toString === 'Done');
if (inProgressTransition && doneTransition) {
const cycleTimeDays =
(new Date(doneTransition.created) - new Date(inProgressTransition.created))
/ (1000 * 60 * 60 * 24);
console.log(`Cycle time: ${cycleTimeDays.toFixed(1)} days`);
}
One thing to watch: this finds the first transition to In Progress. If an issue bounced back from Done to In Progress and back again (which happens) you'll want to decide whether you want total active time or just first-to-last.
The number most teams ignore
The gap between lead time and cycle time is waiting time and that's usually where the actual problem is.
Average lead time: 15 days
Average cycle time: 4 days
─────────────────────────────
Waiting time: 11 days
If 11 of your 15 days are pre-work queue time, optimizing your development process won't move the number customers see. The problem is upstream, backlog grooming, prioritization, how long issues sit before anyone picks them up.
Teams that only measure cycle time tend to optimize the wrong thing. Execution looks fine on their dashboards. Meanwhile the backlog is 6 weeks deep.
When to use which
Cycle time: use this for internal process work. Did the new PR review policy make things faster or slower? Are bugs taking longer than features? Is there a particular engineer whose issues have much longer cycle times (sign of blocked work, not slow work)?
Lead time: use this for anything external. Setting delivery expectations with clients, tracking whether SLA commitments are realistic, understanding the actual experience of someone who filed a request.
Both together: use this when diagnosing a slowdown. Lead time up, cycle time flat: the problem is pre-development. Both up: it's in execution. Lead time flat, cycle time up: execution is slower but the backlog is moving faster, which might mean better prioritization is masking a process issue.
What Jira still won't tell you
Even with cycle time and lead time figured out, there's a gap: time per workflow status how long an issue sat specifically in In Review vs. In QA vs. Waiting for Deployment.
An issue with a 6-day cycle time might have spent 1 day in development, 4 days waiting for code review, and 1 day in QA. Without the per-status breakdown, you'd target the wrong stage.
Jira Cloud doesn't surface this natively. The Control Chart shows you the aggregate; the status-level view requires the changelog API (same approach as cycle time above, but aggregated per status) or a reporting tool that does the work for you. The Jira time tracking reports guide covers what's available natively, what needs JQL workarounds, and where the gaps are if you want a fuller picture of where time actually goes.
Summary
| Cycle time | Lead time | |
|---|---|---|
| Starts at | Work begins (In Progress) | Issue created |
| Ends at | Issue done | Issue done |
| Answers | Is execution fast? | What does the customer wait? |
| Native in Jira | Approximated (Control Chart) | Not directly |
| Use for | Internal process improvement | Stakeholder commitments, SLAs |
The JQL query and API snippet above cover the manual path. If you want this without writing extraction code, most reporting add-ons for Jira handle the aggregation, but knowing what the numbers actually count is still on you.
One last thing worth saying: most teams I've talked to who "track cycle time" are actually tracking something closer to calendar days in the sprint, not time from first status transition. That's not cycle time. It's a rough proxy that includes weekends, holidays, and all the time the issue sat assigned but untouched. Worth auditing how your tooling actually calculates it before drawing conclusions from the numbers.
Top comments (1)
This is a great breakdown. One thing I'd add is that teams often jump to optimizing development speed when the real bottleneck is work waiting to be prioritized or reviewed. Looking at both lead time and cycle time together gives a much clearer picture of where delays are happening.
I've also found that keeping workflow statuses consistent in Jira makes these metrics far more reliable. If teams use "In Progress" or "Done" differently across projects, comparisons become misleading.
Thanks for sharing such a practical explanation—it's a useful reminder that metrics are only valuable when everyone understands what they're actually measuring.