Lead Time vs Cycle Time: The One You Track Is Probably the Wrong One

Lead time measures how long customers wait from request to delivery. Cycle time measures how long your team spends actively working from “start” to “done.” The difference is the queue. If you only track cycle time, you’ll miss the biggest source of delay in enterprise software: work sitting idle in backlogs, approval gates, and handoffs.

What’s the difference between lead time and cycle time, in plain English?

Lead time is customer-facing wait time. Cycle time is team-facing work time. Lead time starts when a request is made (or committed) and ends when it’s delivered. Cycle time starts when work actually begins and ends when it’s finished.

Here’s the framing most teams don’t use, and should: lead time is what your stakeholders feel; cycle time is what your team controls directly. The space between them is where organizations hide delay, then act surprised when “engineering is slow.”

• Metric | Start point | End point | Best for
• Lead time | Request received (or item committed) | Delivered to user/customer | Customer experience, forecasting, service levels
• Cycle time | Work starts (pull into progress) | Work finishes (done) | Flow efficiency, WIP limits, team throughput

This terminology is consistent with common Lean and Kanban usage. If you want a clean baseline definition set, the glossary at Kanbanize’s lead time vs cycle time overview aligns with what many tools implement.

Why do enterprise teams confuse lead time vs cycle time so often?

They confuse them because their tracking systems start the clock too late. Most enterprise workflows don’t record “request received” in a way engineering trusts, so teams start measuring at “In Progress” and call it lead time.

Jira is a common culprit, not because it’s a bad tool, but because teams use “Created date” as noise and “In Progress” as truth. When that happens, you’re not measuring how long work takes. You’re measuring how long it takes after someone has already fought through prioritization, clarification, and approvals.

That missing time is often the majority of delay. Little’s Law makes the math blunt: lead time grows as WIP grows, and enterprise backlogs are basically unbounded WIP. The classic statement of Little’s Law is widely referenced; a practical version for software flow shows up in many Lean texts and in tool write-ups like Atlassian’s agile metrics overview, which connects WIP and time-to-deliver in approachable terms.

One sentence you can use with executives: cycle time is what happens after you’ve already said “yes.” Lead time includes the time it takes you to say “yes.”

Where should you start and stop the clock for each metric?

You should start and stop the clock at points your organization can observe consistently. The correct boundaries are the ones you can defend in a room with product, engineering, and compliance without hand-waving.

Lead time boundaries that work in real companies

Lead time should start at a point that reflects customer demand. In practice, you have three defensible start options, and you must pick one and stick to it:

• Ticket created: best when support requests drive work (bugs, incidents, customer escalations).
• Item committed: start when a Product Owner commits an item to a delivery window (common in product development).
• Contracted date: start when a commercial promise is made (common in enterprise deals and integrations).

Stop lead time at “released to users,” not “merged to main.” If your org uses feature flags, “released” might mean “enabled for 10% of users” or “enabled for customer X.” Pick the release definition that matches what stakeholders care about. DORA’s research makes this distinction tangible by separating code-level activity from delivery outcomes; see DORA’s research site for how delivery performance is typically framed in modern engineering orgs.

Cycle time boundaries that teams can improve week to week

Cycle time should start when work enters active progress under a WIP limit, and stop when it meets your team’s “done” policy. If “done” is ambiguous, your cycle time will be fiction.

• Start: pulled into “In Progress” (or the first active state), not assigned, not estimated.
• Stop: accepted against Definition of Done, not “code complete.”

In Kanban terms, you’re measuring the time in your system after commitment. Many teams align on this via explicit policies, a core practice in the Kanban Method as described by Kanban University.

Write the boundaries on a one-page metrics policy and review it quarterly. Otherwise every re-org quietly changes your numbers.

What does the gap between lead time and cycle time tell you?

The gap tells you how much time work spends waiting. If lead time is 30 days and cycle time is 6 days, you don’t have a “delivery” problem. You have a queue and prioritization problem.

That gap is also a map. It points to where you’ll get the biggest reduction in customer wait time per hour of effort:

• If cycle time is high: your workflow is heavy. Look for large batch sizes, unclear acceptance criteria, too much rework, or excessive handoffs.
• If the gap is high: your intake and decision process is clogged. Look for overstuffed backlogs, missing triage, dependencies, and governance gates.
• If both are high: you’re overloaded. Reduce WIP first, then fix the workflow.

This is why focusing on cycle time alone can be a management comfort blanket. You can optimize “time in progress” while customers still wait a month for you to start.

My unhedged take: if you’re a product organization, lead time is the primary metric and cycle time is a diagnostic metric. Most teams flip that and then wonder why delivery feels random.

How do you calculate lead time vs cycle time without getting lost in tooling?

You calculate both by sampling real work items and using consistent timestamps. Don’t start with dashboards. Start with 30 recent items, a spreadsheet, and agreement on boundaries.

Here’s a practical method we’ve used with enterprise teams when the Jira workflow is messy and the “truth” is split between Jira, GitHub, and release tooling like LaunchDarkly.

1. Pick one work item type. Start with production bugs or small features, not epics.
2. Pull the last 30 completed items.
3. For each item, capture four timestamps: request received, committed, start in progress, released.
4. Compute:
   Lead time (request-based) = released minus request receivedLead time (commit-based) = released minus committedCycle time = released minus start in progressQueue time = start in progress minus committed (or minus request received)
5. Look at percentiles, not averages. Use 50th and 85th percentile to represent “typical” and “planning-safe.”

Percentiles matter because delivery times are rarely normal distributions. They’re long-tailed. Averages get dragged around by a few ugly items and create false debates. For a solid, non-hand-wavy explanation of why percentiles beat averages in skewed distributions, the NIST Engineering Statistics Handbook is a reliable reference.

Once you’ve done the manual pass, then automate in your tool. Tools like Jira Control Chart or ActionableAgile can help, but only after your boundary decisions are stable. Otherwise you’ll automate confusion.

Which metric should you optimize, and when?

You optimize lead time when the business problem is customer wait time or missed delivery promises. You optimize cycle time when the business problem is unstable execution once work starts. Most teams need both, but not with equal attention.

• If you’re seeing this symptom | Primary metric to watch | What to change first
• Stakeholders say “nothing happens for weeks” | Lead time and queue time | Intake triage, WIP limits upstream, clearer priority rules
• Work starts fast but drags, lots of rework | Cycle time | Smaller batch size, Definition of Done, better refinement
• Teams are “busy” but outcomes don’t ship | Lead time and WIP | Stop starting, reduce parallel work, manage dependencies
• Forecasts are always wrong | Lead time percentiles | Plan with 85th percentile, not averages, then reduce variation

In regulated environments, the biggest gains often come from making waiting visible across approval steps, not squeezing another 5% out of coding time. If your Security review takes 12 days and coding takes 3, you don’t have a “developer productivity” problem.

Teams that adopt explicit WIP limits tend to see more predictable flow because WIP is a direct input to time-in-system. That relationship is a cornerstone of flow thinking and connects back to Little’s Law.

How do you reduce lead time without burning out the team?

You reduce lead time by reducing queues and batch size, then by removing avoidable delays. You don’t reduce lead time by asking people to “go faster.”

Cut queue time first (it’s usually larger than you think)

Queue time grows when you accept more work than you can finish. Put hard limits where work enters the system, not just on the development column. Practical moves that work in enterprise settings:

• Create a weekly triage with a fixed capacity. If triage can only admit 10 items, the rest wait outside the system.
• Use a “Ready” buffer with a cap. If Ready is full, Product can’t push more refined items in.
• Limit concurrent initiatives per team. Two active initiatives per team beats six “in progress” initiatives every time.

Single-sentence reality check.

If you don’t cap intake, your lead time will rise no matter how good your engineers are.

Shrink batch size to reduce both lead time and cycle time

Large stories create long cycle times, and they also create longer queues because they’re harder to start confidently. Split work so a single item can move from start to release in days, not weeks.

• Split by user journey step (onboarding step 1 vs full onboarding).
• Split by risk (do the safe slice first, then the risky edge cases).
• Split by interface (API contract first, UI later).

In practice, teams that can’t split work often have a Definition of Done that’s too broad, or dependencies that are unmanaged. Fix those and splitting becomes normal.

Remove “invisible” waits with explicit policies

Enterprise delivery has waits that don’t show up on burn charts: CAB meetings, security sign-off, design review, UAT scheduling, legal approvals. Put them on the board, timebox them, and make “no response” a measurable state.

In the second half of our own work at AgileHour, we’ve seen teams get meaningful lead time drops simply by enforcing a two-business-day SLA for reviews and by making “waiting for approval” visible as a tracked state. No new tooling. Just clearer agreements.

Frequently asked questions

Is lead time always longer than cycle time?

Yes, if you define them conventionally, because lead time includes waiting before work starts and cycle time does not. If your cycle time is longer, your start or stop points are probably mis-set.

What’s a good lead time for a software team?

A good lead time is one your customers can rely on, typically expressed as a percentile like “85% of small changes ship within 10 days.” The right target depends on risk, release process, and product domain, so benchmark against your own history first.

Should we measure lead time from “ticket created” or “committed”?

Measure both if you can, because “created to committed” shows prioritization delay while “committed to released” shows delivery reliability. If you must pick one, use the start point that matches the promise your stakeholders hear.

Do Scrum teams use cycle time or velocity?

Scrum teams often default to velocity, but cycle time is usually better for forecasting small items because it reflects flow and variability item by item. Velocity can still help capacity discussions if you keep batch sizes stable and avoid gaming it.

Can we compare lead time across teams?

You can compare lead time only if teams share the same start and stop definitions and similar work types. Otherwise you’ll reward teams that redefine “done” and punish teams doing higher-risk work.

What to do next if your metrics aren’t changing behavior

Pick one decision you want to improve, then align the metric to that decision. If the decision is “what can we promise by end of month,” use lead time percentiles. If the decision is “why are we stuck once work starts,” use cycle time and break it down by workflow state.

Run a 30-item audit, publish the boundaries, and review them like any other policy. Then set one operating rule tied to the metric, like “Ready column capped at 12” or “reviews answered within two business days.” Metrics that don’t change policies become trivia.