Cycle Time vs. Lead Time: Why the Difference Matters

Smiling person in layered hair w/eyelashes,gesturing

Published on 18 June 2026 by Zoia Baletska

Two measurement spans over one piece of work, one starting earlier than the other.

Cycle time and lead time get used interchangeably in Agile conversations, and the swap is easy to make: both are measured in days, both are said to describe delivery speed, and both go up when things are going badly. But they measure different stretches of the same timeline, and a team can improve one while the other gets worse. That is not a rounding error — it is the reason engineering and leadership can look at the same delivery and disagree about whether it was fast.

What cycle time measures

Cycle time is the clock that starts when someone picks the work up and stops when the work is done. Nothing before the start counts. A ticket that sat in the backlog for a month and then took two days to build has a cycle time of two days.

That makes cycle time a measure of the delivery machine: how long a piece of work takes once it has somebody's attention. It is the number that responds to smaller batches, fewer handovers, faster review and less context switching, which is why engineering teams tend to reach for it first.

What lead time measures

Lead time starts earlier and ends later. The clock starts when the request is raised and stops when the result is in production or in the customer's hands. Everything in between counts — including all the time nobody was working on it.

That makes lead time a measure of the experience on the other side of the request. Someone asked for something; how long until they had it? The answer includes prioritisation, queueing, approvals and release windows, none of which show up in cycle time at all.

One delivery timeline with four points — request raised, work starts, work done, in production. Lead time spans all four; cycle time covers only the stretch between work starting and work finishing. The rest is waiting.

The same ticket, two honest answers

A feature request arrives on Monday. It waits two weeks in the backlog for prioritisation. Development takes four days, review takes two, and it ships in the following week's release.

The engineering team reports a cycle time of six days and is right. Leadership experienced three weeks and is also right. Neither party is spinning the number; they are reading different spans of the same line. This is why delivery dashboards can look healthy while stakeholders keep saying things feel slow — the dashboard is measuring the part that was already fast.

Where the gap comes from

Whatever lead time covers and cycle time does not, is waiting. So the gap between the two is not a measure of engineering at all — it is a measure of everything wrapped around engineering. When that gap is wide, the usual causes are structural rather than technical:

work sitting in the backlog because prioritisation happens on a slower cadence than delivery
requirements that arrive incomplete, so the clock starts before the work can actually begin
approval chains that add calendar time without adding decisions
dependencies on another team's queue, where your work is not their priority
release windows that hold finished work until a scheduled date

None of those are fixed by making developers faster, which is why a team can shorten cycle time for two quarters and hear no difference from the business. The reverse also happens: a batch of work clears the backlog, lead time drops sharply, and nothing about the delivery machine changed.

How DORA's lead time for changes fits in

There is a third span that gets folded into these conversations and should not be. Lead time for changes, one of the four DORA metrics, is measured from commit to running in production. It starts later than lead time in the Kanban sense — the request, the backlog wait and often the first part of development are already behind you when the first commit lands.

So the three are nested, not interchangeable: lead time contains cycle time, and lead time for changes overlaps the end of both. If a report says "lead time" without saying where the clock starts, the number cannot be compared to anything.

Measuring both without gaming either

Both metrics are trivially easy to improve by changing when the clock starts, which is the failure mode to design against. If cycle time is measured from a status change a person controls, it will drift downwards without delivery getting faster. A few things keep the numbers honest:

define the start and end points once, in writing, and use the same definition across teams
take the timestamps from the systems of record — the issue tracker and the deployment pipeline — rather than from a status someone sets by hand
report the distribution, not just the average: a median with a long tail is a different problem from a slow middle
always show the two together, because either one alone can be improved at the other's expense

Which one should you look at?

Look at cycle time when the question is about how the team works: batch size, review load, handovers, work in progress. Look at lead time when the question is about how the organisation works: intake, prioritisation, dependencies, release cadence.

The most useful reading is the pair over time. Cycle time stable while lead time grows means work is getting stuck before or after engineering touches it, and no amount of engineering effort will show up in the answer. Both shrinking together is the only version that means what people usually think "we got faster" means. Pulling both from the same source, alongside deployment frequency, is what turns a debate about speed into a question with an answer.