The one-line version
Lead time — from the moment the request arrives until it is delivered. What the person waiting experiences.
Cycle time — from the moment someone starts work until it is delivered. What the team spends.
Lead time is always the larger of the two. The difference between them is queue time: how long the request sat in a backlog while nobody was working on it.
Why the gap is the interesting number
A team with a lead time of 30 days and a cycle time of 2 days does not have a slow team. It has a queue. Hiring another engineer will not fix it, and pushing the team to work faster will fix 2 days out of 30.
A team with a lead time of 6 days and a cycle time of 5 days has the opposite problem, and the opposite fix.
Both teams have the same complaint arriving from stakeholders — "this takes forever" — and the same complaint has two completely different causes. Reporting only cycle time hides the first team's problem entirely, which is how a backlog grows for a year while every sprint report looks healthy.
Where the boundaries sit in Jira
Jira sorts every status into one of three status categories, whatever you named the status itself:
| Category | Typical statuses | Boundary |
|---|---|---|
| To Do | Backlog, Selected for Development, Triage | Lead time starts at creation |
| In Progress | In Progress, In Review, QA, Blocked | Cycle time starts here |
| Done | Done, Closed, Released, Won't Do | Both end here |
So cycle time runs from the first transition into any In Progress status to the first transition into any Done status, and lead time runs from the issue's creation date to that same Done transition.
Using categories rather than status names is what makes this survive a workflow that calls things Development, Build and Shipped. It also means a miscategorised status silently corrupts the number. A "Ready for Development" status that somebody created in the In Progress category will start the clock while the issue is still queueing, and your cycle time will quietly absorb the queue you were trying to separate out. It is worth checking once.
The two decisions nobody documents
What counts as done
If an issue reaches Done, gets reopened, and reaches Done again, which transition ends the clock? Taking the first is the common choice and makes reopened work look fast. Taking the last counts the rework, which is usually what you wanted to know. Either is defensible; being inconsistent about it is not.
Whether the weekend counts
For forecasting a delivery date, calendar time is honest — the customer waits through the weekend too. For judging whether code review is slow, working time is fairer — nobody was at their desk on Saturday.
The same interval reads very differently:
Calendar time, Friday afternoon to Monday morning
Working time, weekend and holidays excluded
Neither is wrong. Reporting one without saying which is.
Measuring both in Jira
Jira's Control Chart plots cycle time for completed issues and shows the trend. It will not give you a number for one issue, it does not split the time by status, and there is no lead time report at all.
TimeInColumn computes both from the same status history, per issue, with the average, median and 85th percentile beneath:
| Key | Assignee | To Do | In Progress | In Review | Cycle | Lead |
|---|---|---|---|---|---|---|
| CMS-7 | Dana | 4h | 1d 2h | 3h | 1d 5h | 2d 1h |
| CMS-8 | Omri | 12d | 2d 4h | 6h | 3d 2h | 15d 2h |
| median | 6d 2h | 1d 15h | 4h | 2d 3h | 8d 13h |
CMS-8 has a healthy cycle time and a terrible lead time. Twelve of those fifteen days were spent in To Do, where nobody was working on it.
Use the median, not the average. One issue that sat open for eight months drags an average somewhere no real issue lives. The 85th percentile is the one to quote to stakeholders: "85% of our work finishes within nine days" is a promise you can keep, and an average is not.