Learning Objectives
By the end of this lesson you will be able to:
- Define Lead Time and Cycle Time precisely
- Calculate each from ticket creation and state change timestamps
- Identify the four most common delay patterns revealed by comparing the two
- Explain how to use these metrics to have productive improvement conversations
The Two Clocks
Imagine a customer order placed on Monday. The team starts work Wednesday. It ships Friday.
- Lead Time: Monday to Friday — 5 days. The customer's perspective: how long from request to delivery.
- Cycle Time: Wednesday to Friday — 3 days. The team's perspective: how long from active work to delivery.
The 2-day gap (Monday to Wednesday) is queue time — time the request spent waiting before anyone touched it.
This distinction is everything. If your Lead Time is 10 days but your Cycle Time is 2 days, you don't have an execution problem — you have a prioritization and queue management problem.
Formal Definitions
Lead Time = time from when a request enters the system (ticket created, request received) to when it's delivered (deployed, customer has it).
Cycle Time = time from when a team member actively starts working on it to when it's delivered.
Some teams define Cycle Time differently (e.g., from "In Progress" to "Done"). What matters is consistency — define it once, measure it the same way every time.
How to Measure
In most issue trackers (Jira, Linear, GitHub Issues):
- Lead Time start: Ticket creation date / issue open date
- Cycle Time start: First transition to "In Progress" (or equivalent active state)
- End for both: Ticket closure / deployment date
Most teams have this data already. The challenge is generating a report that aggregates it.
Pro Tip: Average Lead Time and Cycle Time are useful. But percentiles are more useful. Your P50 (median) tells you what a typical item looks like. Your P95 tells you what happens to the unlucky 5% — and that's usually where your biggest problems are hiding.
The Four Delay Patterns
Pattern 1: Large Lead Time, Small Cycle Time
The gap between Lead and Cycle is huge. Work sits in the queue for a long time before anyone touches it.
What it means: Too many items in the backlog competing for attention; poor prioritization; or a "start everything, finish nothing" culture.
Fix: Limit WIP (Work in Progress). The team should be finishing things, not starting things.
Pattern 2: Large Cycle Time, Consistent Lead Time
Items take a long time once started.
What it means: Stories are too large; too many dependencies; or there are handoff delays (Dev writes code, QA waits in queue, Dev waits for review...).
Fix: Slice stories smaller. Map the handoffs and reduce wait time at each step.
Pattern 3: High Variance in Cycle Time
Average looks fine, but individual items range from 1 day to 3 weeks.
What it means: The process isn't standard. Some items breeze through; others get stuck. Often caused by unclear acceptance criteria or hidden dependencies discovered mid-work.
Fix: Improve refinement so stories are more predictably scoped before they start.
Pattern 4: Both Times Growing Over Sprints
Both Lead Time and Cycle Time are trending upward.
What it means: The team is accumulating technical debt, the backlog is growing faster than delivery, or the team is being asked to do more than they have capacity for.
Fix: This is a systemic signal, not a process tweak. Needs a leadership conversation.
Using the Metrics in Practice
Don't present Lead Time and Cycle Time as abstract numbers. Tell a story with them:
"Our average Cycle Time is 3 days, but our average Lead Time is 11 days. We're spending 8 days in queue before work even starts. If we could halve that queue time, we'd cut customer wait time significantly without the team working any harder."
That's a compelling, data-backed improvement conversation.
Summary
Lead Time is the customer's clock; Cycle Time is the team's clock. The gap between them reveals queue time — often the biggest hidden waste in a development process. Measuring both, comparing them over time, and diagnosing the pattern puts you in a position to drive real process improvement rather than guessing.