Cycle Time vs Lead Time: The Simple Guide

Finally understand why features take 6 weeks when coding takes 5 days.

Why This Matters to You

Your CEO asks: "Why does it take 6 weeks to ship a simple feature?"

Engineering says: "We only need 5 days to build it."

Customers complain: "We've been waiting 6 weeks!"

Everyone's right; they're just measuring different things.

This confusion causes:

• Missed expectations with stakeholders
• Optimizing the wrong parts of your process
• Frustrated customers who only care about their wait time

Most teams confuse these metrics¹. After reading this guide, you won't be one of them.

The Core Distinction (In Plain English)

Start With Everyday Examples

Restaurant Order:

• Lead time: From placing order to eating your meal (30 minutes)
• Cycle time: Actual cooking time (10 minutes)
• The rest: Waiting for waiter, order queue, plating, delivery (20 minutes)

Package Delivery:

• Lead time: From clicking "buy" to package at your door (5 days)
• Cycle time: Actual shipping time (2 days)
• The rest: Processing, warehouse queue, sorting (3 days)

In Software Development:

Customer Request → [WAITING] → Dev Starts → [WORKING] → Deployed

|←---------------- Lead Time (Customer Wait) ----------------→|
                              |← Cycle Time (Active Work) →|

Lead Time (What Customers Care About)

Simple definition: Total time from request to delivery.

• Clock starts: Customer asks for something
• Clock stops: Customer can use it
• Includes: Everything, waiting, working, testing, deploying
• Who cares: Customers, executives, sales
• Example: "We requested this feature in January, got it in March" = 2 months lead time

Cycle Time (What Teams Track)

Simple definition: Time spent actually working.

• Clock starts: Developer picks up the task
• Clock stops: Code is deployed
• Excludes: Time sitting in backlog
• Who cares: Engineering teams, scrum masters
• Example: "We started coding Monday, deployed Friday" = 5 days cycle time

Why Work Waits 85% of the Time

Flow efficiency measures how much of the total time work is actively worked on.

Flow Efficiency = How much time work is actually being worked on

In plain English:

• If a feature takes 30 days total (lead time)
• But only 5 days of actual work (cycle time)
• Flow efficiency = 5 ÷ 30 = 17%
• Your work waited 83% of the time!

Think of it like aircraft at the gate. Most delays aren't from flying (coding) but from ground operations, waiting for gates, boarding, refueling, clearances. This is normal, not a failure.

Typical software teams: 5-15% flow efficiency².

Why this matters: You can't make developers code 10x faster. But you can eliminate wait time.

Calculation Methods

Precision matters. Here's how to calculate correctly.

Lead Time Calculation

1. Mark request date: Jira ticket timestamp, email received, request logged
2. Mark delivery date: Live in production, customer can use it
3. Calculate calendar days between these dates

Example:

• Request logged: March 1
• Delivered: April 15
• Lead Time: 45 calendar days

Cycle Time Calculation

1. Mark work start: Ticket moves to "In Progress"
2. Mark completion: Deployed to production
3. Calculate working days between these dates

Example:

• Development starts: April 8
• Deployed: April 15
• Cycle Time: 5 working days

Multi-Stage Tracking (Finding Where Time Goes)

Let's track a simple bug fix first, then scale up:

Simple Bug Fix Example:

• Reported to picked up: 2 days waiting
• Fixing the bug: 2 hours working
• Waiting for review: 1 day waiting
• Review: 30 minutes working
• Waiting for deployment: 1 day waiting
• Total: 4 days waiting, 2.5 hours working

Now a Feature (More Complex):

Lead Time: 35.5 days Cycle Time: 7 days Flow Efficiency: 19.7%

Try It Now

Practice with your data:

Example Scenario:

• Request Date: January 15
• Development Starts: February 20
• Deployed: March 5

Results:

• Lead Time: 49 days
• Cycle Time: 13 days
• Flow Efficiency: 26.5%

Industry Benchmarks

Know where you stand.

Flow Efficiency Benchmarks

Source: Reinertsen, "Principles of Product Development Flow"²

DORA Lead Time Benchmarks

Source: DORA State of DevOps Report³

Cycle Time by Work Type

Real-World Examples

Amazon's Two-Pizza Teams

Problem: Long lead times from communication overhead.

Solution: Small, autonomous teams owning services end-to-end. Eliminated handoffs.

Result: Cycle time stayed similar. Lead time dropped dramatically⁴.

Spotify's Squad Model

Problem: Two-week sprints, but months-long lead times from dependencies.

Solution: Autonomous squads with clear missions. Minimal external dependencies.

Result: Single-squad features shipped much faster⁵.

Toyota Production System

Principle: Eliminate waste (they call it "muda"). In software, waiting is the biggest waste.

Focus: Reduce time in queues, not coding speed.

Result: Faster delivery without pushing people harder⁶.

Common Misconceptions

1. "Lead Time Starts When We Begin Coding"

Wrong! Lead time starts when the customer asks, not when you start working. Why it matters: You're hiding most of the wait time.

2. "We Only Count Working Days"

Wrong! Customers experience calendar days, including weekends. Why it matters: A "5-day" task taking 2 weeks feels slow to customers.

3. "Let's Make Developers Code Faster"

Wrong! The problem isn't coding speed, it's waiting. Why it matters: Work waits 85% of the time. Fix the waits, not the workers.

4. "Average All Tasks Together"

Wrong! Bug fixes and features have different patterns. Why it matters: A 1-day bug fix and 20-day feature average to meaningless "10.5 days."

5. "High Cycle Time Is Bad"

Not always! Complex work naturally takes longer. Why it matters: Focus on the ratio (flow efficiency), not just one metric.

AI Prompts for Flow Analysis

Pipeline Analysis

Analyze this delivery pipeline data: [paste workflow timestamps]
- Calculate lead and cycle time for each item
- Identify wait states and duration
- Calculate flow efficiency
- Find biggest bottleneck
- Recommend top 3 improvements

Bottleneck Identification

Find bottleneck in this process:
Stages: [Design: 2d, Dev: 5d, Review: 3d, Test: 2d]
Team: [5 engineers, 1 designer, 1 QA]
WIP limits: [Dev: 5, Review: 3]

Identify:
- Primary constraint
- Queue locations
- Wait/work ratio per stage
- Theory of Constraints recommendations

Metric Selection

Which metric for this scenario:
Scenario: [Presenting to C-suite]
Stakeholder: [CEO and COO]
Goal: [Show improved market responsiveness]
Problem: [Features feel slow]

Recommend:
- Primary metric
- Supporting metrics
- Simple narrative

Advanced Techniques (Made Simple)

Little's Law (The Most Useful Formula You'll Learn)

What it measures: How long things will take based on how much you're juggling.

The formula in plain English:

Wait Time = Stuff in Progress ÷ Completion Rate

Real example:

• You have 20 features in progress (WIP)
• You complete 5 features per week (Throughput)
• Expected wait time = 20 ÷ 5 = 4 weeks

What this tells you: Want faster delivery? Stop starting new things. Finish what's in progress.

Other Useful Techniques

Cumulative Flow Diagrams: A visual chart showing work piling up at each stage. Bottlenecks appear as widening bands.

Value Stream Mapping: List every step from idea to customer. Mark which steps add value (coding) vs waste (waiting).

Control Charts: Track your metrics over time. Helps you spot real problems vs normal variation.

How to Improve Both Metrics

To Reduce Lead Time (Make Things Flow Faster)

This week you can:

1. Limit work in progress (WIP): Set a team rule: "No more than 2 items per person"
2. Make work visible: Put all waiting work on a board where everyone sees it
3. Reduce batch size: Break big features into smaller pieces that ship independently

This month you can:

1. Remove approval bottlenecks: Automate or delegate routine approvals
2. Create cross-functional teams: Include design, dev, and QA in one team
3. Shorten your backlog: Keep only 2-3 sprints of refined work ready

To Reduce Cycle Time (Make Work Go Faster)

This week you can:

1. Block focus time: Team agrees on 2-hour "no meeting" blocks daily
2. Pair on complex work: Two people often finish faster than one
3. Define "done" clearly: Prevent rework from unclear requirements

This month you can:

1. Improve your tools: Faster build times, better CI/CD
2. Pay down technical debt: Dedicate 20% of capacity to code cleanup
3. Level up skills: Lunch-and-learns, pair programming, mentorship

Which Metric to Use When (Your Cheat Sheet)

Lead Time Conversations

With CEO/Executives: "Our average lead time is 30 days from request to delivery."

With Customers: "You can expect this feature in 4-6 weeks from today."

For SLA Commitments: "We commit to 21-day delivery for standard features."

Template: "From the time you request it to when you can use it will be [X] days."

Cycle Time Conversations

With Engineering: "Our cycle time is averaging 5 days per story."

In Sprint Planning: "Based on cycle time, we can complete 4 stories this sprint."

For Estimation: "Similar features took 3-5 days of actual work."

Template: "Once we start working on it, it typically takes [X] days to complete."

When You Need Both

In Retrospectives: "We have 5-day cycle time but 30-day lead time. Let's find the wait states."

For Process Improvement: "Our 15% flow efficiency shows we can improve without working harder."

Getting Started This Week (Day-by-Day Plan)

Monday (10 minutes)

1. Pick your last completed feature
2. Find when it was requested (email, ticket, meeting notes)
3. Find when it was deployed
4. Calculate: That's your lead time
5. Find when coding started: That's your cycle time

Tuesday (15 minutes)

1. Calculate flow efficiency: Cycle time ÷ Lead time
2. If it's below 20%, you're normal
3. If it's below 10%, you have big opportunities

Wednesday (30 minutes)

1. List all the stages work goes through
2. For each stage, note: Who owns it? What are they waiting for?
3. Circle the stage with the longest wait

Thursday (20 minutes)

1. Talk to your team about the longest wait
2. Ask: "What would reduce this wait by half?"
3. Pick one simple improvement to try

Friday (10 minutes)

1. Set up basic tracking in your tool (Jira, Azure DevOps, etc.)
2. Create two fields: "Work Started" and "Request Date"
3. Share what you learned with your team

Next Week

Track 5 more items. Look for patterns. Share findings in your retro.

Key Takeaways

• Lead time = what customers feel. Cycle time = what teams do.
• Your work waits 85% of the time. This is normal and fixable.
• Stop trying to code faster. Start eliminating waits.
• Use lead time with executives, cycle time with engineers.
• Doing less at once (lower WIP) beats doing things faster.

Next Steps

Optimize your delivery flow:

1. Calculate metrics with our Cycle/Lead Time Calculator
2. Track Sprint Velocity for capacity planning
3. Monitor Quality Metrics alongside speed
4. Learn about Managing Technical Debt

Remember: Customers don't care how fast you code. They care how long they wait.

References