Cycle Time vs Lead Time: Definitions and Formulas

Cycle time vs lead time is one of the most common points of confusion in lean, agile, and operations work. They're related, but they measure different clocks -- and mixing them up leads to bad decisions about where to improve your process.

What is lead time?

Lead time is the total time from when a customer request arrives to when that request is delivered. The clock starts the moment demand is placed -- a purchase order, a support ticket, a user story -- and stops only when the customer has the finished output in hand.

Lead time includes everything: time spent waiting in a queue, time blocked on approvals, time in active work, and time in transit. It's the number the customer actually experiences, even though most of that time your team may not be touching the work at all.

Example. A customer submits a software feature request on Monday morning. Your team picks it up Wednesday, codes it Thursday and Friday, tests it the following Monday, and deploys it Tuesday. The customer's feature is live nine business days after the request arrived. Lead time = 9 days.

Key Facts: cycle time and lead time

• Little's Law, first proven by operations researcher John D. C. Little in 1961, shows that average lead time equals average work in progress (WIP) divided by average throughput. It applies to any stable system -- manufacturing, software, support.
• The Lean Enterprise Institute's research on value stream mapping consistently finds that over 80% of lead time in most processes is queue and wait time, not active work time. Cutting lead time almost always means cutting wait, not working faster.
• According to Accelerate (Forsgren, Humble, and Kim, 2018), elite software delivery teams achieve median lead times for changes under one hour. Most organizations start at days or weeks.

What is cycle time?

Cycle time is the time it takes to complete one unit of work once your team actually starts on it. The clock starts when active work begins, and it stops when that unit is done and ready for the next stage (or for delivery). Cycle time does not include time sitting in a backlog or waiting for someone to pick it up.

In manufacturing, cycle time is often measured per unit: "How long does one item take to move through a workstation?" In software and Kanban, it's typically the time from "in progress" to "done."

Example. Using the same feature request: your team picks up the work Wednesday, codes through Friday, tests Monday, deploys Tuesday. Active work time = 5 business days. Cycle time = 5 days. Lead time = 9 days. The gap of 4 days was queue time before work started.

Cycle time is an internal metric. Your team controls it. Lead time is the customer-facing metric that depends on both cycle time and the wait time upstream of work.

Cycle time vs lead time: the key differences

Here's a side-by-side comparison of the two metrics.

The gap between the two numbers is your queue time: the time a request spends waiting before anyone touches it. A large gap usually signals a backlog problem, not a speed problem. If your lead time is 10 days but cycle time is 2 days, the process is spending 8 days waiting, not working.

How to calculate cycle time and lead time

Both formulas are straightforward. The challenge is agreeing on exactly when each clock starts and stops in your specific process.

Lead time formula

Lead time = Delivery date and time minus Request date and time

For a batch or average: add up lead times across a set of completed items and divide by the number of items.

Cycle time formula

Cycle time = Completion date and time minus Start of active work date and time

For a team average over a period: divide total output by the number of working periods.

Little's Law

Little's Law is the most useful formula connecting both metrics:

Lead time = Work in progress (WIP) / Throughput

Where:

• Work in progress (WIP) is the number of items currently being processed (started but not finished)
• Throughput is the number of items completed per unit of time

If your team completes 5 tickets per week and always has 20 tickets in progress, Little's Law predicts an average lead time of 4 weeks. To cut lead time in half, you can either double throughput (hard) or cut WIP in half (often easier and faster). This is why WIP limits are a central practice in Kanban and lean systems.

Little's Law works on any stable process -- a call center, a software sprint, a warehouse picking station -- as long as the flow rate is roughly steady.

How to reduce cycle time and lead time

Reducing both metrics starts with knowing which one is actually the problem.

Step 1: Measure both separately

Set up tracking that records request arrival time, work start time, and completion time for every unit. Most project tools and Kanban boards can do this with minimal configuration. You can't improve what you can't see.

Step 2: Identify where time is actually going

Draw a simple value stream map of your process. Mark which stages involve active work and which are pure wait. If your lead time is 10 days and your cycle time is 2 days, focus first on the 8 days of wait.

Step 3: Limit work in progress

Per Little's Law, cutting WIP directly cuts lead time. Set explicit WIP limits at each stage. When a stage hits its limit, pull work only when a slot opens. This feels slower but almost always results in faster overall flow because it stops the pile-up that causes queue time.

Step 4: Remove blockers before they recur

Track why items get stuck: missing approvals, dependencies on other teams, unclear requirements, waiting for environment access. Use root cause analysis or a five whys session to get at the repeating patterns, then fix the system rather than chasing each individual blocker.

Step 5: Balance your workstations or team capacity

Uneven capacity creates bottlenecks that inflate both cycle time and lead time. The theory of constraints gives you a framework for finding the one constraint that limits the entire system -- fix that first, and the rest of the flow speeds up. You can also apply poka-yoke techniques to prevent defects that cause rework and extend cycle time.

Step 6: Shrink batch sizes

Large batches of work move slowly through a system even when individual cycle times are short. Splitting a two-week feature into daily deployable slices cuts lead time dramatically because feedback arrives sooner and queue time drops.

Cycle time vs lead time examples

The support and procurement examples show a pattern that just-in-time thinking targets: the actual work is a small fraction of total elapsed time. Most of the lead time is handoff, queue, and approval overhead.

Takt time, cycle time, and lead time

These three terms often appear together, and they serve distinct purposes in lean operations.

Takt time is the target rate at which your process must produce one unit to match customer demand. It's set by the market, not by your team. If customers demand 100 units per 8-hour shift, takt time is 4.8 minutes per unit. Takt time is a planning tool.

Cycle time is what your process actually takes per unit. If cycle time is below takt time, you have capacity. If cycle time exceeds takt time, you can't meet demand. Takt time sets the benchmark; cycle time tells you how close you are.

Lead time is the end-to-end customer experience, which includes cycle time plus all the wait before and after active work.

The three work together: takt time tells you the target pace, cycle time shows your actual pace per unit, and lead time reveals the total wait the customer experiences from request to receipt.

Frequently asked questions

What is the difference between cycle time and lead time?

Lead time is the total time from customer request to delivery, including all waiting periods. Cycle time is only the active work time once a task or unit has been started. Lead time is always greater than or equal to cycle time. The difference between the two is queue time.

Is lead time always longer than cycle time?

Yes, in practice. Cycle time is a component of lead time, so lead time equals cycle time plus any waiting time before and after active work. The only scenario where they'd be equal is if work starts the instant a request arrives and is delivered the moment it's finished -- which almost never happens in real operations.

What is Little's Law and why does it matter?

Little's Law states that average lead time equals average WIP divided by average throughput (items completed per unit of time). It matters because it gives you a lever: instead of trying to work faster (throughput), you can cut WIP directly to reduce lead time. Lower WIP means each item moves through the system faster with less competition for resources.

Can you have a low cycle time but a high lead time?

Yes, and it's common. If your team is fast once they start working but requests sit in a backlog for days before being picked up, cycle time will be short while lead time stays high. This is exactly the scenario that WIP limits and pull-based systems are designed to address.

How do Kanban boards track these metrics?

Most Kanban tools (Jira, Linear, Trello, and similar) record the timestamp when a card moves to an "in progress" column and when it moves to "done." Cycle time is the gap between those two events. Lead time is tracked from card creation (or the point of customer request) to done. Many tools generate cumulative flow diagrams that show WIP, throughput, and predicted lead time all in one chart.

---

Reducing cycle time and lead time isn't about pushing people to move faster. It's about removing the wait that fills the space between real work. Map your flow, cap your WIP, and fix the bottlenecks -- the numbers follow.