Cycle Time vs Lead Time: What’s the Difference?

What is the difference between cycle time and lead time?

cycle time vs lead time is a key topic in modern project management and teamwork. Cycle time is the elapsed time from starting work on an item to finishing it. Lead time is the elapsed time from the moment a request is made or accepted to the moment the result reaches the person who asked for it. The difference is everything that happens before work starts and after it is nominally done.

That sentence sounds simple and is routinely ignored. The reason is that both metrics are often described as “how long work takes”, and the definitions shift by industry and by tool. Manufacturing engineers, Kanban practitioners, and DevOps teams each draw the start line in a slightly different place.

The fix is not to memorise one universal definition. It is to write down your own, explicitly, and use it consistently. A precise definition applied consistently beats an orthodox definition applied loosely.

A working pair that covers most project and service work:

• Cycle time starts when an item enters “in progress” — the moment a person or team actually begins.
• Lead time starts when the item is requested, submitted, or committed to by the team.
• Both stop at the moment of delivery, not at internal “done”. If a finished item sits in a release queue for a week, that week belongs to lead time.

That last clause matters more than it looks. Teams love to declare done at the point they stop working, because it is the point they control. Customers only experience the point where they receive something usable.

How are both metrics measured in practice?

You measure them with timestamps at defined transitions, recorded automatically where possible, and you report distributions rather than averages. The definition matters less than the discipline of applying one definition to every item.

Four timestamps give you both metrics:

With those four points you can compute the two metrics and one diagnostic:

• Cycle time = T3 − T2
• Lead time = T4 − T1
• Queue time = T2 − T1, and release delay = T4 − T3

This decomposition is the most useful thing in the whole article. When lead time is bad, the decomposition tells you whether to fix the queue, the work, or the release. Most teams skip straight to the work, because that is the part they enjoy and control.

> Common mistake: Changing the definition mid-stream and then comparing the numbers. If “cycle time” meant start-to-merge last quarter and start-to-release this quarter, your trend line is fiction.

Why is the gap between them usually so large?

Because queue time normally dominates, and nobody owns the queue. In most workflows an item spends far more time waiting for attention than being worked on, and the waiting is distributed across many small, invisible decisions.

Think about a feature request. It arrives on Monday. It waits for triage. It waits for a design slot. It waits for the next sprint boundary. It waits for review. It waits for a release window. Each wait is short and locally reasonable. Summed, they dwarf the two or three days of actual work.

This is not a moral failure of the team. It is the natural result of several independent scheduling decisions, each optimised for the person making it. Nobody wakes up intending to add four days of queue.

There is a second reason the gap is large: work in progress. When a team starts more than it can finish, everything slows down, including items that would have been quick. A ten-minute approval task sits behind three large ones because it entered the same queue. Queueing theory is unforgiving here — wait times rise steeply as utilisation approaches capacity, not linearly.

And a third: release batching. A team that ships monthly has a lead time that includes up to a month of finished-but-undelivered work. Reducing cycle time does nothing for that month until the release cadence changes.

What does Little’s Law tell you about lead time?

Little’s Law says the average number of items in a system equals the average arrival rate multiplied by the average time each item spends in it. Rearranged for delivery work: average lead time = average work in progress ÷ average throughput.

The practical implication is blunt. If throughput is fixed, the only way to shorten lead time is to reduce the number of items in progress. Working faster helps, but limiting WIP helps immediately and predictably.

Example 1: a support desk with a backlog

A support team receives about 500 tickets a month and works roughly 21 days a month, so throughput is about 24 tickets per working day. At any time there are 80 open tickets.

Average lead time = 80 ÷ 24 ≈ 3.3 working days.

Now the team halves the open queue to 40 by resolving or closing stale tickets and tightening intake. Throughput stays the same. Average lead time becomes 40 ÷ 24 ≈ 1.7 working days. Nobody worked faster. The wait halved because there was less in the queue.

Example 2: a content pipeline

A content team has 18 articles in progress — drafting, review, design, publishing — and publishes 4 per week.

Average lead time = 18 ÷ 4 = 4.5 weeks.

The team believes its cycle time is five days, which is true for drafting. But a request sits 2.5 weeks before drafting starts, and finished drafts sit another week waiting for design and scheduling. Cutting drafting from five days to three would improve lead time by roughly 0.3 weeks. Capping work in progress at 8 and fixing the design handoff would cut it by more than two weeks.

That comparison is the argument for measuring both metrics. The team’s instinct — work faster — was worth days. The queue was worth weeks.

Can a team have short cycle time and long lead time?

Yes, and it is the most common failure pattern in delivery work. It happens whenever intake is unconstrained: the team is efficient at the work it starts, but it starts too much and the backlog absorbs the efficiency.

The fourth pattern deserves a note. In low-demand environments, long cycle time can be harmless because nothing waits. Optimising it is a hobby, not an improvement.

So which metric should you manage?

Manage lead time as the outcome and cycle time as the diagnostic. Lead time is what the customer experiences and what commitments are made against. Cycle time tells you whether the delay is inside the work or around it.

The levers differ, and using the wrong one wastes months:

To shorten lead time, work on the queue:

• Cap work in progress and make the cap real, not advisory.
• Limit intake — say no, or say “later”, with a date.
• Reduce batch size so items move in smaller pieces.
• Remove approval steps that add days and catch nothing.
• Shorten release cadence so “done” and “delivered” converge.

To shorten cycle time, work on the process:

• Map the value stream and find the largest waiting step *inside* the work.
• Reduce handoffs; each one adds a queue.
• Fix the rework loop — the review that sends 40% of items back is a cycle time problem.
• Improve test and verification speed, which is usually the tail of the process.
• Give people the information they need at the start, so work does not stall mid-flight.

Notice that only one item appears on both lists: batch size. It is the highest-leverage change in flow work because it affects queue and process at the same time.

> Practical tip: Report lead time at the 50th and 85th percentile, not the mean. Averages hide the tail, and the tail is where your customers get angry. If p50 is 6 days and p85 is 21 days, your process has a predictability problem that the average conceals.

How do cycle time and lead time relate to other flow metrics?

They form a family, and mixing them up produces confident nonsense. Throughput is the count of items finished per period. Work in progress is the count started but not finished. Touch time is the subset of cycle time spent in active effort. Flow efficiency — sometimes called cycle time efficiency — is touch time divided by lead time.

Example 3: flow efficiency in an approvals process

A contract review takes 90 minutes of actual legal work. From submission to signature, the elapsed time is 11 working days, or about 88 hours at eight hours a day.

Flow efficiency = 1.5 ÷ 88 ≈ 1.7%.

The work is not slow. The waiting is. Any proposal to “speed up legal review” by 20% would save 18 minutes. Any proposal to review twice a day instead of once would save days. The metric points at the right intervention, which is the entire purpose of measuring.

What about lead time in software delivery?

In DevOps, “lead time for changes” usually means the time from code committed to code running in production. DORA’s research programme uses it as one of four delivery metrics, alongside deployment frequency, change failure rate, and time to restore service.

DORA’s classic tiering has described elite performers as delivering changes with a lead time of under one hour, while low performers measure in weeks or months. That spread is not mainly about typing speed. It is about batch size, automation, and approval design — the same levers that govern any queue.

Two cautions when borrowing these benchmarks:

1. The definition is narrower than yours. DORA’s clock starts at commit, not at request. It excludes discovery, design, and prioritisation, which may be most of your customer’s wait.
2. Benchmarks are context, not targets. A regulated medical-device release and a marketing site deploy are not comparable. Compare your own trend, and compare against your own definition.

For flow work in general — support tickets, content, hiring, procurement — the queue is usually the dominant term, and the queue is a decision-making problem rather than a technical one.

How do you improve both without gaming the numbers?

Make the measurement automatic, keep the definition in writing, and review the distribution rather than a single number. Any metric attached to individual performance will be optimised in ways that damage the system.

Five rules keep the data honest:

1. Timestamp transitions, not recollections. Manual estimates drift toward round numbers and optimism.
2. Count abandoned and cancelled items. Excluding them makes the process look faster than it is; include them with a separate status.
3. Do not delete outliers. Investigate them. One 40-day item usually reveals a real failure mode.
4. Report percentiles. p50 for the typical case, p85 or p95 for the promise you make.
5. Never rank individuals by cycle time. It rewards small, easy items and punishes the person handling the difficult work everyone else avoids.

There is a trade-off worth naming. Tighter WIP limits shorten lead time but reduce the appearance of activity — fewer things “in progress” can feel like less work happening, especially to managers who equate busyness with output. Expect that pushback, and answer it with delivered items per week rather than with reassurance.

Common mistakes to avoid

• Treating the two terms as synonyms. They answer different questions and need different interventions.
• Starting lead time at “when we began”. That is cycle time with a different name, and it hides the queue your customer actually feels.
• Optimising cycle time in a queue-bound system. You will celebrate a 10% improvement while the customer waits three weeks.
• Averaging. A mean of 8 days can hide a p85 of 30. Report the shape.
• Ignoring items that never finish. Cancelled and abandoned work belongs in the data.
• Comparing across teams with different item sizes. Normalise by size class, or compare trends within one team over time.
• Using the metric as a productivity score. The moment it becomes a target, items get split and start dates get backdated.

Where Doitify fits

Both metrics depend on timestamps that most teams already generate but rarely keep in one place: when a task was created, when it entered progress, when it was completed, and when it shipped.

Doitify keeps that history on the task itself — Kanban boards with explicit columns, task and sub-task owners and due dates, sprint and backlog views, Gantt and calendar views for planned dates, plus work and performance reports that show flow over time. Because the board state changes are recorded against the task, cycle time and lead time come from the same dataset rather than from a monthly spreadsheet reconciliation.

The honest limitation, and Doitify is our product so weigh this section accordingly: it reports what your columns and statuses capture. If your board has one “in progress” column for everything from design to deploy, the data will be too coarse to separate queue from work. Fixing the workflow matters more than changing the tool.

Conclusion

Cycle time tells you how fast the team works. Lead time tells you how long the customer waits. The distance between them is the queue, and in most systems the queue is where the time actually goes.

If you remember one thing, make it the decomposition: lead time = queue + cycle time + release delay. Measure all three once, and the argument about where to invest usually resolves itself within a week. Then cap work in progress, because it is the one lever that moves both numbers at the same time — and it costs nothing but the discipline to stop starting so much.

If this post on cycle time vs lead time was helpful, you might also enjoy Capacity Planning in Project Management (2026 Guide) and Project Management Software With Workload Management.