Cycle Time vs Lead Time: Which Clock to Promise a Client

Cycle time is the time from when work starts on an item to when it finishes; lead time is the time from when the request was made to when it is delivered. Lead time is always equal to or longer than cycle time, and the difference is queue time. Promise lead time to a client, because it is the clock they experience.

In short. Cycle time = finish minus start of work. Lead time = delivery minus request. Queue time = start of work minus request. A team that reports only cycle time can watch it improve for months while the customer waits longer, because tightening what happens after work starts does nothing about how long a request waits before anyone picks it up.

Ask a team if delivery has gotten faster and they will often point to a cycle time chart trending down. Ask their customers and the answer is frequently the opposite. Both can be true at once, because the two metrics run on different clocks. The same logic sits behind DORA's delivery metrics, which report "lead time for changes" (commit to running in production) rather than only the time spent building: the reported number is deliberately the one that includes the wait. Kanban University's Little's Law material (2022) makes the same point from the other side: at steady throughput, the only way to shorten the time an item spends in a system is to lower the work in progress.

Cycle Time vs Lead Time: Two Clocks, One Item

Every piece of work has both numbers attached to it, and they start at different moments.

Worked example. A client asks for a report change on Monday the 1st. Nobody starts it until Thursday the 4th, and it ships on Monday the 8th. Queue time is 3 days, cycle time is 4 days, and lead time is 7 days. The team's board shows "4 days." The client waited 7.

Cycle time is a subset of lead time. If a request sits for five days before anyone starts on it, then takes three days of actual work, cycle time is three days and lead time is eight. A dashboard that only shows cycle time reports "3 days," which is accurate and also not what the requester experienced.

Why the Two Numbers Diverge

The divergence almost always comes from an unmanaged intake queue. WIP limits cap how much work is actively in progress, which is good discipline and genuinely lowers cycle time by Little's Law: less work in progress at a constant throughput means less time each item spends being actively worked. But a WIP limit says nothing about how long a request waits in the backlog before it's pulled into that capped stage. Tighten the cap without also watching the backlog, and requests can queue longer even as the in-progress metric improves, because the same completion rate is now spread across more of a wait that isn't being tracked at all.

This is the exact failure mode a cumulative flow diagram catches if the backlog is included as its own band. A backlog band that widens while the in-progress band holds steady is queue time growing in plain sight, weeks before it shows up as customers asking where their request went.

The diagram below plots both clocks for the worked example above, showing where each one starts.

Both bars describe the same request from the worked example. The team's internal chart, cycle time only, shows 4 days. The customer's actual wait, lead time, was 7, and the 3 days between them are the queue. Neither number is wrong; they're answering different questions, and only one of them is the question the customer asked.

Measuring Lead Time Without Guessing

1. Timestamp the request the moment it arrives, not the moment someone triages it. A ticket filed on Monday and triaged on Thursday has a lead-time clock that started Monday.
2. Timestamp delivery, not "marked done." If a completed item sits waiting for deployment or sign-off, lead time hasn't ended until the customer actually has it.
3. Track queue time as its own number, the gap between the two timestamps above, rather than inferring it. A queue that's growing is the earliest signal that lead time is about to diverge from cycle time.
4. Report lead time externally, cycle time internally. A sponsor or client cares about the number that matches their experience; a team improving its own process cares about the number it directly controls.
5. Watch both trends, not just their current values. Cycle time improving while lead time flattens or worsens is the specific pattern that means the queue is the actual bottleneck, not the workflow.

Which Number to Promise a Client

Promise lead time. It's the number a customer or stakeholder can verify against their own experience, and a lead time promise implicitly accounts for the queue, which a cycle time promise doesn't. If a request sits for a week before anyone starts and the team then delivers in two days, a cycle-time-based promise of "two days" is technically true and will read as a broken commitment to whoever waited the full nine.

Reserve cycle time for internal process improvement conversations, where the team controls the variable it's measuring. Reducing WIP, catching bottlenecks earlier with a cumulative flow diagram, and applying Little's Law to forecast the effect of taking on more work are all cycle-time-side interventions. Comparing velocity and throughput gives the delivery-rate side of the same picture. None of them touch queue time on their own, which is why a team serious about the number customers actually feel needs to manage the backlog as deliberately as it manages the workflow.

More explainers on flow and delivery metrics are in the Onplana blog.

Run the free Status Report Writer Turn this week's actual cycle time and delivery dates into a status update that reports the number your stakeholders experience, not just the one your board tracks. No signup required. → Open the Status Report Writer