Cycle time vs lead time: the difference that changes decisions

Ask three engineering leaders to define these two metrics and you will get five definitions. That's a problem, because the distinction isn't pedantry — it points to two completely different failure modes, with two completely different fixes. Conflate them and you will "optimize" the wrong thing.

The definitions, precisely

Lead time

Lead time = completed date − created date

Lead time is the clock your stakeholders experience. It starts when the ticket is created — when someone asked for the thing — and stops when the work is delivered. It includes every minute the item sat in a backlog, waited for prioritization, or was blocked behind other work. The requester doesn't care about any of those internal distinctions. They asked on the 1st; they received on the 19th; the lead time was 18 days.

Cycle time

Cycle time = completed date − first "in progress" date

Cycle time is the clock your delivery system experiences. It starts when someone actually begins work — the task first enters an in-progress status — and stops at done. It measures execution: coding, review, testing, deployment, and all the waiting between those stages.

By definition, cycle time is always a subset of lead time. The remainder is queue time:

Lead time = queue time + cycle time

Why the distinction changes your diagnosis

The two metrics fail in different ways, and each failure has a different owner and a different fix. When leadership says "delivery is slow", the first analytical question should be: which clock is long?

• Long lead time, short cycle time — a queue problem. Work executes quickly once started, but sits waiting for weeks. The fix is not "engineers work faster" — it's starting less, prioritizing more often, and cutting work-in-progress. This is a management fix, and pushing the team harder makes it worse by adding more WIP.
• Long cycle time — an execution-system problem. Work drags once started. Almost always this is wait time inside the workflow: pull requests waiting days for review, tickets parked in QA, deployments batched to Fridays. A per-status bottleneck analysis finds the stage where hours of work take days of calendar.
• Both long — start with the queue. Reduce WIP first. Lower WIP mechanically shortens both clocks (Little's Law: WIP = throughput × cycle time), and it exposes the true execution bottleneck instead of burying it under a pile of half-started work.

Which one do you show leadership?

Both — but for different conversations. Lead time is the promise-keeping metric: it answers "when will we deliver what was asked?" and it's the number to discuss with product and executives. Cycle time is the operations metric: it answers "how healthy is our delivery machine?" and it's the number for engineering's own retrospectives and improvement work.

A useful executive framing: "Our cycle time is 4 days, but our lead time is 30 — we don't have an engineering speed problem, we have a commitment and sequencing problem." That single sentence, backed by data, redirects an entire quarter of misplaced pressure.

Measurement pitfalls that ruin both metrics

Averages lie — use percentiles

Delivery time distributions are heavily right-skewed: most items finish quickly, a few take forever. An average blends those regimes into a number that describes neither. Report the 85th percentile ("85% of tasks finish within N days") — it's more honest, and it's directly usable for forecasting commitments.

Define "started" mechanically

If "started" means "an engineer moved the card", cycle time inherits every workflow-hygiene habit on the team. Derive it from the first transition into an in-progress status, and hold the definition constant. Changing the definition mid-quarter invalidates every trend line you've built.

Don't confuse it with DORA's "lead time for changes"

The DORA framework's lead time for changes measures commit-to-production — the delivery pipeline only. Customer lead time as described here starts at the request, long before the first commit. Both are valuable; they are different instruments. (Full breakdown in What are DORA metrics?)

Watch the trend, not the number

There is no universal "good" cycle time — a firmware team and a web team live in different physics. What is universal: stable or shrinking percentiles are healthy; a widening gap between P50 and P85 means growing unpredictability, and it will surface as missed commitments a quarter later.

How teams actually reduce them

• Limit WIP. The single highest-leverage change. Finish before starting. Lead time falls without anyone typing faster.
• Shrink batch size. Smaller tasks flow faster, forecast better, and fail cheaper. If your stories routinely take three weeks, the stories are too big.
• Attack the review queue. In most teams, code review wait is the largest single component of cycle time. Make review turnaround a team norm, not a personal favor.
• Prioritize on a cadence. Queue time balloons when prioritization happens "whenever". A weekly sequencing ritual keeps the request-to-start clock short and honest.

Measuring both automatically from ClickUp

Everything above assumes you can actually see these numbers — most teams can't, because computing status-history math across thousands of tasks isn't a spreadsheet job. TheMetrics reads your ClickUp status history through read-only OAuth and computes lead time, cycle time, queue time, and per-status bottleneck breakdowns continuously, sliced by team, list, and sprint. See how it works on the ClickUp analytics page.