Lead time vs cycle time is one of the most practically important metric distinctions in flow-based project management, yet it remains one of the most frequently confused. Both measure the duration of work through a system, but they measure different portions of that journey — from different starting points — and provide different insights for different audiences. Getting this distinction right is not merely academic: organisations that confuse lead time with cycle time misinterpret their delivery performance data, set incorrect customer expectations, and implement process improvements that address the wrong problem. This guide explains both metrics clearly, shows how they relate through Little’s Law, and demonstrates how to use each effectively in project delivery.
Defining Lead Time
Lead time is the total elapsed time from when a customer or stakeholder makes a request to when that request is fulfilled. It begins the moment a work item enters the system — when a customer submits a feature request, when a support ticket is raised, when a user story is added to the product backlog — and ends when the completed work is delivered to the requester. Lead time includes all waiting time: time spent in the backlog queue, time waiting for development to start, time in active development, time in review and testing, and time waiting for deployment.
Lead time is the customer-facing metric. It answers the question stakeholders, customers, and sponsors actually care about: “How long will it take from when I ask for something to when I receive it?” A customer does not care whether their request spent 15 days in a backlog queue and only 3 days in active development — they experience the full 18-day lead time and form their satisfaction judgement on that basis. Lead time is therefore the primary SLA (Service Level Agreement) metric in most Kanban and service delivery contexts.
Defining Cycle Time
Cycle time is the elapsed time from when active work begins on an item to when that work is completed. It starts when a developer picks up the story, when the support engineer begins investigating the ticket, when the designer starts the wireframe — and ends when the work is done and ready for delivery. Cycle time excludes waiting time in queues before active work begins. It measures only the period of active processing.
Cycle time is the team-facing efficiency metric. It answers the question the delivery team cares about: “How long does it take us to complete something once we start working on it?” Cycle time is within the team’s direct control — it reflects the team’s working practices, technical capability, collaboration effectiveness, and process efficiency. Improving cycle time requires improving how the team works; improving lead time also requires improving queue management and demand versus capacity alignment.
The Relationship: Lead Time = Queue Time + Cycle Time
The mathematical relationship between lead time and cycle time is straightforward: Lead Time = Queue Wait Time + Cycle Time. A story that waits 10 days in the backlog before development starts, then takes 3 days to complete, has a cycle time of 3 days and a lead time of 13 days. Most organisations are surprised to discover how large the queue component of their lead time is — measurements frequently reveal that items spend 80–90% of their total lead time waiting in queues rather than being actively worked on. This ratio — the proportion of lead time that is active processing versus waiting — is called flow efficiency, and it is one of the most revealing metrics in Lean and Kanban analysis.
“Most organisations are shocked when they first measure flow efficiency. Discovering that work is actively being processed only 10–15% of the time is the wake-up call that drives meaningful improvement.” — Mike Burrows, Agendashift
Little’s Law: The Mathematical Bridge
Little’s Law — L = λW, or equivalently Cycle Time = WIP ÷ Throughput — provides the mathematical relationship between WIP, throughput, and cycle time. For project managers, its practical implication is powerful: if throughput is relatively stable, the only lever available to reduce cycle time (and therefore lead time) is reducing WIP. This is why Kanban’s WIP limits are so effective — they mechanically enforce the WIP reduction that Little’s Law shows will reduce cycle time. The relationship is not a management opinion or a best practice — it is a mathematical law that applies to any stable queuing system.
Measuring Lead Time and Cycle Time
Both metrics require accurate timestamps for each work item: when it entered the system (for lead time), when active work began (for cycle time start), and when it was completed (for both metrics’ end). Most modern project management tools — Jira, Linear, Azure DevOps, ClickUp — capture these timestamps automatically through column transitions on the Kanban board, making historical flow analysis straightforward without additional data collection effort. The important setup requirement is ensuring that column definitions on the board accurately reflect when active work starts and ends for cycle time measurement purposes.
Individual lead time and cycle time measurements are less meaningful than distributions and trends. The 50th percentile (median) cycle time tells you how long half of items take. The 85th percentile tells you what you can promise with 85% confidence. The 95th percentile identifies outliers — items taking significantly longer than typical — that deserve individual investigation. Tracking the 85th percentile cycle time over time is a reliable indicator of whether process improvements are actually reducing delivery time at a system level.
Lead Time vs Cycle Time: Practical Applications
| Question | Metric to Use | Why |
|---|---|---|
| “When will my request be delivered?” | Lead Time | Includes all waiting time the customer experiences |
| “How efficient is our development process?” | Cycle Time | Measures active processing efficiency only |
| “Where is time being wasted in our flow?” | Lead Time − Cycle Time | Queue time reveals waiting waste locations |
| “What can we commit to for our SLA?” | Lead Time 85th percentile | 85% of requests delivered within this time |
| “How is our team improving over time?” | Cycle Time trend | Shows whether team process is becoming more efficient |
Key Takeaways
- Lead time measures from customer request to delivery — it includes all queue waiting time and is the customer-facing SLA metric.
- Cycle time measures from work start to work done — it excludes queue time and is the team efficiency metric reflecting process and capability.
- Lead Time = Queue Wait Time + Cycle Time — most teams discover that 80–90% of lead time is queue wait, not active work — a finding that redirects improvement efforts from development speed to queue management.
- Little’s Law proves that reducing WIP is the primary lever for reducing cycle time when throughput is stable — this is the mathematical basis for Kanban’s WIP limits.
- Use lead time percentiles (50th, 85th, 95th) for SLA commitments — percentile-based promises are honest about variability in a way that average promises are not.
- Track cycle time trend over time as the primary indicator of whether process improvement efforts are actually working at the system level.
