Cycle Time vs Lead Time: The Only Agile Metrics You Need?

Cycle Time vs Lead Time: The Only Agile Metrics You Actually Need?

Most teams I coach can tell me their story points velocity to two decimal places.
Almost none can tell me their average cycle time or lead time.

And that’s backwards.

If you care about predictability, stakeholder trust, and not burning out your team, then cycle time and lead time matter more than velocity, burndown charts, or story points. Those other metrics can be useful, but they’re secondary.

Let’s unpack why.

---

The Two Metrics That Actually Tell You the Truth

What Is Lead Time?

Lead time is how long it takes from the moment someone asks for something to the moment it’s in production and usable.

• Start: Idea requested / ticket created / request accepted
• End: Feature live in production and available to users

It answers:

“If I ask for this today, when will I get it?”

This is the metric your stakeholders, customers, and business leaders actually care about, whether they use the term or not.

What Is Cycle Time?

Cycle time is how long it takes from the moment the team starts working on something to the moment it’s done.

• Start: Work starts (e.g., “In Progress” in your board)
• End: Work is done and ready for release (or released, depending on your definition of done)

It answers:

“Once we start, how long does it usually take to finish?”

This is the metric your delivery team should obsess over.

Why These Two Beat Everything Else

Velocity, story points, and burndown charts are proxies. They try to approximate how fast you’re going.

Cycle time and lead time are actual timing data. They are:

• Objective – Measured in days/hours, not “points”
• Comparable – Easy to compare across teams, quarters, and initiatives
• Directly tied to flow – They show you how work moves (or doesn’t) through your system

When you know your lead time and cycle time, you can:

• Give realistic delivery forecasts instead of hand-wavy “two to three sprints”
• Spot bottlenecks (e.g., review, testing, deployment)
• Reduce context switching and multitasking
• Improve team focus and reduce stress

---

A Simple Example: Why This Matters in Real Life

Imagine a team that:

• Says they have velocity of 40 points per sprint
• Runs two-week sprints
• Ships “most” stuff in 1–2 sprints

On paper, that looks fine.

Now we look at their actual data:

• Median lead time: 32 days
• Median cycle time: 11 days
• 85th percentile cycle time: 21 days (15% of items take 3+ weeks once started)

What’s happening?

• Work sits waiting to be started for weeks.
• Once started, some items get stuck in review, QA, or blocked by dependencies.
• Stakeholders experience the team as slow and unpredictable, even though the team “hits velocity.”

This is common. In one large org I worked with:

• Teams had “stable velocity” for months
• But their average lead time increased from ~18 days to ~45 days over a year
• Nobody noticed until we started tracking lead time and cycle time

Velocity looked fine. Delivery reality was getting worse.

---

Lead Time vs Cycle Time: How They Work Together

Think of your process like a restaurant:

• Lead time: From when you order to when the food arrives at your table
• Cycle time: From when the chef starts cooking your dish to when it’s ready

If:

• Lead time is huge, but cycle time is reasonable → You’re queuing too much work
• Cycle time is huge → Your actual execution is slow or constantly interrupted
• Both are huge → You’re overloaded and your process is broken

You need both metrics to know:

• Are we starting too many things at once?
• Are we blocked by handoffs, approvals, or unclear requirements?
• Are we batching work into massive, slow-moving items?

---

How to Actually Measure Cycle Time and Lead Time (Without Overcomplicating It)

Step 1: Decide Your Start and End Points

Be explicit. For most software teams:

• Lead time start: Ticket created and accepted into a backlog that the team commits to serving

• Lead time end: Deployed to production and available to users

• Cycle time start: Ticket moved to “In Progress”

• Cycle time end: “Done” (meets your Definition of Done; ideally deployed)

Write this down and agree as a team. Ambiguity kills metrics.

Step 2: Use Your Existing Tooling

Jira, Azure DevOps, GitHub Projects, Trello, etc. already track timestamps.

• Pull timestamps based on column transitions (e.g., To Do → In Progress → In Review → Done)
• Export data weekly or use a plugin/automation
• Calculate:
  • Average and median lead time
  • Average and median cycle time
  • 85th or 95th percentile (for forecasting)

Step 3: Visualize Flow, Not Just Averages

Don’t just look at a single average number.

Use:

• Scatter plots (cycle time per ticket over time)
• Cumulative flow diagrams (to see where work piles up)
• Histograms (distribution of cycle times)

These quickly show:

• Outliers (tickets that took 40 days when most take 5)
• Trends (are we getting faster or slower?)
• Bottlenecks (e.g., review column always full)

---

Common Mistakes Teams Make With Cycle Time and Lead Time

Mistake 1: Tracking Them but Not Changing Behavior

Collecting metrics is not the goal. Using them to make decisions is.

If your standups, retros, and planning sessions never reference cycle time or lead time, you’re just generating charts for dashboards nobody reads.

Use these questions regularly:

• “Why did this item take 22 days when our median is 6?”
• “Why is ‘In Review’ always the longest state?”
• “What changed last month when our lead time jumped?”

Mistake 2: Measuring the Wrong Thing (Or Too Much)

Some teams obsess over:

• Lines of code
• Number of commits
• Story points completed
• Hours logged

These are activity metrics, not outcome metrics.

Cycle time and lead time are enough to guide flow improvement. Don’t drown in vanity metrics.

Mistake 3: Using Metrics to Blame People

If you use cycle time to say “Alice is slow” or “Team B is underperforming,” you will:

• Get fake data
• Encourage gaming the system
• Destroy psychological safety

Metrics are for systems thinking, not individual judgment. Focus on:

• Process bottlenecks
• Hand-offs
• Dependencies
• Overloaded WIP

Mistake 4: Ignoring Work Item Size

If your tickets range from:

• “Update button color”
  to
• “Rebuild the entire billing system”

…your cycle time chart will be chaos.

Huge variance in ticket size leads to:

• Unpredictable cycle times
• Useless averages
• Frustrated stakeholders

You don’t need perfect slicing, but you do need roughly similar-sized work items.

Mistake 5: Treating Lead Time as “Not Our Problem”

I see this a lot:

“We only control development. Lead time includes backlog, approvals, legal, etc. That’s outside our scope.”

That’s convenient, but wrong.

If your overall lead time is bad, your customers don’t care which department is slow. Work with:

• Product to refine and prioritize earlier
• Design to reduce back-and-forth
• Security/legal to create standard patterns and checklists

You can influence the system, not just your column on the board.

---

How to Improve Cycle Time and Lead Time (Without Heroics)

1. Limit Work in Progress (WIP) Ruthlessly

Nothing kills cycle time like too much WIP.

If everyone is:

• Juggling 3–5 tickets
• Constantly context-switching
• “Almost done” with everything

…your cycle time will be awful.

Actionable steps:

• Set explicit WIP limits per column (e.g., “In Progress” max 3 items)
• When a column hits its limit, swarm to finish work instead of starting new work
• Track how often you hit WIP limits and discuss in retro

2. Make “Blocked” Highly Visible and Painful

Blocked work silently inflates cycle time.

Actionable steps:

• Add a “Blocked” tag or lane on your board
• Track time spent blocked separately
• In standup, always ask:
  • “What’s blocked?”
  • “Who can help unblock it today?”
• Escalate chronic blockers (e.g., slow approvals) as systemic issues, not one-off annoyances

3. Shorten Feedback Loops Aggressively

Long review and testing cycles are common culprits.

Actionable steps:

• Move to smaller pull requests (e.g., aim for < 300 lines changed)
• Set review SLAs (e.g., PR reviewed within 24 hours)
• Automate as much testing as possible
• Pair or mob program for risky or complex changes

4. Slice Work Smaller (But Not Microscopic)

You don’t need one-day tickets for everything, but you do need to avoid month-long monsters.

Actionable steps:

• During refinement, ask:
  • “What’s the smallest version of this that delivers value?”
  • “Can we ship behind a feature flag?”
  • “Can we split UI and backend changes into separate deployable steps?”
• Avoid “epic tickets” – keep work items at a size that typically completes within a few days to a week

5. Use Percentiles for Forecasting, Not Wishful Thinking

Stop saying:

“We think we can do this in 2 sprints.”

Instead, use your actual data:

• If your 85th percentile cycle time is 8 days, you can say:
  • “Once we start an item, there’s an 85% chance it will be done within 8 days.”
• For a batch of 10 items, you can estimate:
  • “Historically, 85% of items like this finish within 8 days once started, so we expect the batch to take about X–Y weeks.”

That’s data-driven forecasting, not optimism.

---

Are Cycle Time and Lead Time Really the Only Metrics You Need?

If your goal is:

• More predictable delivery
• Better stakeholder communication
• Healthier, less chaotic teams

…then yes, they’re enough to start with.

You don’t need:

• Elaborate “agile maturity” dashboards
• Ten different charts updated daily
• Complex point systems

You need:

1. Lead time – Are we delivering value fast enough from request to production?
2. Cycle time – Once we start, how long do we take to finish?

Once those are under control, you can layer in:

• Defect rates
• Deployment frequency
• Customer satisfaction (NPS, support tickets, etc.)

But if you’re struggling today, don’t start there. Start with flow.

---

Bringing This Into Your Team’s Daily Rhythm

To make cycle time and lead time real, not theoretical:

• In standup:
  • “What’s been in progress the longest?”
  • “What’s blocked right now?”
• In refinement:
  • “Can we split this to keep cycle time under a week?”
• In retro:
  • “Our median cycle time went from 6 to 9 days. What changed?”
  • “Where did work sit the longest this sprint?”

You don’t need a giant tooling overhaul. Even simple tools work, as long as they support focused conversations. For example, when you’re refining or running retros about why certain items took so long, a lightweight tool like ScrumPoi lets you quickly estimate, vote anonymously, and capture insights without forcing the team through heavy setup.

---

Conclusion: Stop Worshipping Velocity, Start Optimizing Flow

If you remember nothing else:

• Lead time is what your stakeholders feel.
• Cycle time is what your team can control day to day.
• Both are more honest and useful than story points alone.

You don’t need a jungle of agile metrics. You need a clear view of how long work takes to move through your system, and the courage to change how you work when the data tells you something’s broken.

Start measuring cycle time and lead time for the next month.
Talk about them in every retro.
Make one concrete improvement each sprint.

You’ll be surprised how quickly your delivery becomes more predictable—and how much calmer your team feels when the work finally flows.