Lead Time vs. Cycle Time
Measuring what customers feel vs. what workers experience.
1Definitions That Matter
These terms are frequently confused but crucially different:
Lead Time: The total elapsed time from when a customer makes a request to when they receive the value. This is what the customer experiences. It includes all waiting, all processing, everything.
Cycle Time: The time work spends being actively worked on. This is what workers experience during their portion of the stream.
Example: A customer requests a feature on Monday. It's prioritized and pulled into development on Wednesday. A developer works on it for 2 days. It sits in PR review for 3 days. Testing takes 1 day. It's deployed on Friday of the following week.
- Lead Time: 12 days (Monday to Friday of week 2)
- Cycle Time (Development): 2 days
- Cycle Time (Review): A few hours
- Cycle Time (Testing): 1 day
Notice: the active work was maybe 4 days total. The lead time was 12 days. Eight days were waiting.
The Metric You Probably Track Is Wrong
Most teams track cycle time or velocity—what workers produce. But customers don't care about your velocity. They care about lead time—how long they wait. Optimize for what customers feel, not what looks good internally.
2Where the Gap Comes From
The gap between lead time and cycle time is wait time. And wait time typically dominates.
Queue time: Work sitting in backlogs, waiting to be prioritized, waiting for someone to pick it up.
Handoff delays: Work done in one stage, waiting for the next stage to have capacity.
Batching delays: Work that's finished but waiting to be deployed with other work.
External dependencies: Waiting for other teams, vendors, or approvals.
Calendar delays: Work that's ready but "we only deploy on Tuesdays."
In most software organizations, wait time is 80-95% of lead time. That means only 5-20% of the time, work is actually being worked on.
The implication: improving how fast you work has minimal impact. If you work twice as fast but waits stay the same, lead time barely changes. The leverage is in the waits.
A simple bug fix: 2 hours of developer time. But: 3 days waiting for assignment, 2 days waiting for PR review, 1 day waiting for QA, 3 days waiting for the weekly deploy, 2 days monitoring in production. Lead time: 11 days.
Same bug fix, different team: PR reviewed within hours (small PRs, team priority on review). No QA queue (developers test their own code). Continuous deployment (no deploy windows). Lead time: 3 hours.
3Touch Time and Wait Time
Another useful breakdown:
Touch Time: Time when work is actively being progressed by a human. Hands on keyboard. Brain engaged on this problem.
Wait Time: All the time in between. In queues. Waiting for review. Waiting for deployment. Waiting for information.
Processing Time: Touch time plus machine time (builds, tests, deploys). This is cycle time.
When you understand this breakdown, you can target improvements correctly:
- Long touch time but high value-add? Probably not waste—this is skilled work.
- Long touch time but low value-add? Potential waste—automate or eliminate.
- Long wait time? Almost certainly waste—reduce batches, limit WIP, eliminate queues.
Most teams try to make touch time faster (better tools, more developers) when the problem is wait time (too much WIP, batching, queues). It's like trying to make cars go faster when they're stuck in traffic.
If you have a lead time problem, you probably have a wait time problem. If you have a wait time problem, you probably have a WIP problem. Reducing WIP is usually the fastest path to shorter lead times.
- Lead time is what customers experience; cycle time is work time
- The gap between them is wait time—usually 80-95% of lead time
- Improving work speed has minimal impact on lead time
- Wait time is usually the biggest leverage point for improvement
- Track lead time as your primary metric—it's what customers feel