Lead Time vs. Cycle Time

The Definitions

The terminology in this area is notoriously inconsistent. The cleanest definitions used in modern flow practice:¹

• Lead Time: the time from when a customer (or stakeholder) makes a request until the request is delivered. Measured from the customer's perspective.
• Cycle Time: the time from when the team starts work on an item until the work is delivered. Measured from the team's perspective.

The difference is the time the request spent waiting in the queue before the team picked it up. For many real systems, that wait time dwarfs the team's actual work time.

Why The Distinction Matters

Most teams measure only cycle time and report it to stakeholders as "delivery time." From the team's perspective this is honest — they really did the work in that time. From the customer's perspective it is misleading — they've been waiting much longer.

A team that finishes an item in 5 days but had it sitting in the backlog for 60 days has a 5-day cycle time and a 65-day lead time. Telling stakeholders "we deliver in 5 days" while they wait 65 produces friction the team won't understand.

The Beware-the-Vocabulary Note

Different traditions use these terms differently:

• Toyota Production System originally used "lead time" to mean what we now call "cycle time" in service systems.
• Software DevOps (DORA metrics) uses "lead time for changes" specifically to mean code-commit to production — not request-to-delivery.
• Kanban traditions (Anderson, Vacanti) use the definitions in this article.

When teams discuss "lead time," ask which definition is intended. The vocabulary confusion produces real misunderstandings in cross-team conversations.²

The Anatomy of Lead Time

Lead time can be decomposed into:

• Queue time (request waiting before being started).
• Cycle time (active work).
• Possibly delivery delay (work finished but not yet released).

For many teams, queue time is 60–90% of total lead time. Investments that reduce queue time (faster prioritization, shorter backlog, capacity reallocation) often have larger effects on customer-perceived delivery than investments in team execution speed.

Which to Measure

Both, ideally. Most teams should track:

• Cycle time for team-level operational improvement. The team can directly affect this through their own practices.
• Lead time for customer-facing reporting. The stakeholder cares about when their thing arrives, not when the team started it.
• Queue time as a derived metric to surface where wait is occurring.

The Service Level Expectation

Most kanban-mature teams set Service Level Expectations (SLEs) based on cycle time percentiles. For example:

• 50% of items complete within 5 days.
• 85% of items complete within 14 days.
• 99% of items complete within 30 days.

The SLE is more honest than a single "average cycle time" because real cycle time distributions are heavily skewed — a few items take much longer than the median. The 85th-percentile measure captures this reality.

Common Failure Modes

• Reporting cycle time as if it were lead time. Stakeholders hear "we deliver in 5 days" and feel deceived when they actually waited 65.
• Optimizing only cycle time. Cycle time improves; lead time doesn't, because queue time wasn't addressed.
• Using averages instead of percentiles. The average hides the long tail. The 85th percentile is what stakeholders actually experience for "important" items.
• Inconsistent start/done definitions. Different team members start the clock differently, making the metric noisy.

Coaching Tips

Define start and done explicitly.

"Start" is when the card enters the In Progress column. "Done" is when it enters the Done column. Without explicit definitions, the metric is noise.

Report percentiles.

"50%/85%/99%" is more honest than "average." Percentiles match how stakeholders actually experience the work.

Surface queue time explicitly.

Lead time minus cycle time = queue time. If queue time dominates, prioritization is the leverage, not execution.

Be careful with vocabulary.

"Lead time" means different things in different traditions. Always clarify which definition you're using.

Set SLEs from data.

Don't guess "we'll deliver in 5 days." Measure historical performance and quote the 85th percentile honestly.

Plot cycle time as scatter, not bar.

Scatter plots reveal outliers; bar charts hide them. Outliers are the most interesting data points.

Summary

Lead time and cycle time measure related but distinct things, and confusing them produces stakeholder friction. Teams that track both — cycle time for their own improvement, lead time for stakeholder honesty — gain a more accurate picture of how their work actually arrives at the customer. The most leveraged improvements often involve reducing queue time, not cycle time, because queue time is typically the larger component. Both metrics should be reported as percentile distributions rather than averages to reflect real-world variability.

Back to Flow & Forecasting