Cycle Time & Lead Time
Cycle time measures how long work takes from starting to completion; lead time measures the total duration from request to delivery, including wait time before work begins.
What it is
Lead time measures the total duration from when a request is made to when it is delivered. Cycle time measures how long work takes from the moment it is actively started to when it is completed.
The difference between the two is queue time: the period when a request is waiting in a backlog or blocked before work begins.
- Lead time = request to delivery. Includes waiting, analysis, development, testing, and release.
- Cycle time = start to completion. Measures only the active work period.
- Difference is queue time. Long lead times with short cycle times indicate a bottleneck before work starts.
- Measured as averages. Use rolling averages (e.g., over 2 weeks) rather than single data points.
- Reducing cycle time is more controllable. You cannot always control demand, but you can control how quickly work moves through your process.
Lead time answers "When will I get it?" Cycle time answers "How long does it take you to build it?" Both are necessary, but they serve different conversations.
When to use it
Track both metrics continuously. Review trends in retrospectives and use them to forecast delivery dates for stakeholders.
Cycle time is the metric you optimise; lead time is the metric your customers feel.
Key concepts
Lead Time
The total clock time from request to delivery. Includes all waiting and active work. Affected by demand volume, prioritisation speed, and process efficiency.
Cycle Time
The clock time from "In Progress" to "Done." A pure measure of process efficiency. Best tracked per work item type (bug, feature, spike) because different types have different natural durations.
Queue Time
The gap between lead time and cycle time. High queue time usually means the team is starting work faster than it can finish, or that prioritisation is slow.
Throughput
The number of items completed per unit of time (usually per week). Throughput and cycle time are inversely related when WIP is stable.
Variability
Not all work takes the same time. High variability in cycle time suggests inconsistent process, unclear requirements, or unpredictable interruptions.
Plot a scatterplot of cycle time over time. A widening spread means your process is becoming less predictable. A tightening spread means your process is stabilising.
Calculation Walkthrough with Real Numbers
Story: "Add two-factor authentication to login form"
Timeline:
- Monday 9am: Product Owner creates the story in the backlog. This is the request time.
- Tuesday 10am: Developer picks up the story and moves it to "In Progress." (24 hours of queue time—the backlog was busy.)
- Wednesday 4pm: Developer finishes coding and pushes to the "In Review" column. (30 hours of active development.)
- Thursday 10am: Code reviewer approves. Developer moves it to "In Test." (18 hours of review queue.)
- Thursday 3pm: Tester signs off. Item moves to "Done." (5 hours of testing.)
Metrics:
- Lead time: Monday 9am to Thursday 3pm = 78 hours (3.25 days)
- Cycle time: Tuesday 10am to Thursday 3pm = 53 hours (2.2 days)
- Queue time: Lead time - Cycle time = 78 - 53 = 25 hours
- Queue time breakdown: 24 hours waiting in backlog + 18 hours waiting for review = 42 hours (wait, that's more than 25!). Correction: Cycle time should start from when work "truly" starts (after all waiting), so actual active cycle time was 53 - 25 = 28 hours of work. The story took 78 hours end-to-end, but only 28 hours was actual work.
Measuring Cycle Time: From Start to Finish
Start point: When a developer first moves the item to "In Progress" (or marks it started in your tool).
End point: When the item reaches "Done" and is potentially releasable.
What to exclude: Don't include time in the backlog, blocked time due to external dependencies, or time waiting for deployment (unless deployment is part of your definition of "Done").
Measuring practically: Most tools (Jira, GitHub Projects) have timestamp fields for "started" and "completed." If not, record the times manually or add a timestamp to your workflow state transitions.
Measuring Lead Time: From Request to Delivery
Start point: When the request is created (the moment a user story is added to the backlog or a customer request is logged).
End point: When the work is delivered to users (deployed to production, or handed to the customer).
What to include: All waiting, prioritisation time, development, testing, and deployment. If a feature is requested Monday but doesn't start until Thursday because the backlog was full, all 3 days of wait time counts toward lead time.
Practical tip: Lead time is what stakeholders feel. Use it to forecast: "Historical lead time is 10 days average, so this feature will be ready in ~10 days."
What These Metrics Reveal About Bottlenecks
High queue time, short cycle time: Work sits waiting before starting, but moves fast once it starts. Bottleneck is upstream: backlog grooming, prioritisation, or resource allocation.
High cycle time, short queue time: Work starts quickly but moves slowly through development. Bottleneck is the development process: unclear requirements, slow testing, or architectural problems.
High queue time AND high cycle time: Everything is slow. You have multiple bottlenecks. Start with the biggest: is it slow to start work or slow to deliver?
Both short and stable over time: Your process is healthy and predictable. Focus on incrementally improving, not dramatic change.
Percentile Analysis: p85 Cycle Time vs Average
Average cycle time of 5 days can hide a lot. Here's why percentiles matter:
- Average: 5 days
- p50 (median): 4 days. Half the stories finish in 4 days or less.
- p85: 8 days. 85% of stories finish in 8 days. The slowest 15% take longer.
- p95: 12 days. The slowest 5% of work takes 12+ days.
When forecasting: "This story is similar to past stories. Historically p85 is 8 days. I'll commit to 8 days, knowing 15% might slip." Use p85 or p95 for forecasts, not average.
Common pitfalls
| Pitfall | Why it hurts | What to do instead |
|---|---|---|
| Confusing the two metrics | Stakeholders expect delivery dates based on cycle time alone. | Always clarify which metric you are quoting. |
| Including weekends without being explicit | Comparisons become misleading. | Use working days for cycle time; calendar days for lead time, and state which. |
| Comparing across teams | Different definitions of "start" and "done" make comparisons invalid. | Benchmark against your own historical data. |
| Ignoring outliers | One blocked item skews the average for weeks. | Use median or 85th percentile alongside averages. |
| Focusing only on cycle time | Queue time hides upstream dysfunction. | Measure and discuss both metrics together. |
NZ context
In New Zealand, lead time variability is often driven by upstream demand management rather than delivery team speed. Small product teams frequently serve multiple stakeholders who submit requests informally. Without a visible queue, work sits in invisible backlogs for weeks.
Tracking lead time makes this visible. When stakeholders see that "simple" requests take 6 weeks because they sit in a backlog for 5, the conversation shifts from "Why is development slow?" to "How do we prioritise faster?"
Career level guidance
Senior: Own the cycle time metric for your team. Break it down by work item type and look for outliers. If cycle time is creeping up, investigate whether WIP limits are being respected or whether code review is the bottleneck.
Test Lead: Track cycle time specifically for items entering test. If test cycle time is increasing while dev cycle time is flat, testing is becoming the bottleneck. Use this data to advocate for test automation investment or additional test environment stability.