Lead Time vs Cycle Time: Definitions and Use

Lead time measures elapsed time from request to delivery. Cycle time measures elapsed time from starting work to finishing it, including waits within that interval. With the same delivery endpoint, the difference shows waiting before work starts. Track both to distinguish intake delays from delays within delivery.

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

Lead time measures elapsed time from a request to delivery. Cycle time measures elapsed time from when work starts to when it finishes, including waiting within the workflow. Define both boundaries explicitly. When both measures end at delivery, their difference shows the time spent waiting before work started.

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. That hides the real waiting.

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. High-performing teams that use Jira in an agile way tend to be much more explicit about these boundaries.

That missing time is often the majority of delay. Little’s Law makes the math blunt: lead time grows as WIP grows, and an unconstrained backlog can hide a large queue of demand. 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. For teams formalizing their measurement approach, a set of delivery-focused agile metrics can help keep attention on customer outcomes instead of vanity numbers.

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. If you cannot observe it, you cannot improve it.

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.”

With these boundaries, you are measuring elapsed time after work starts, including any subsequent waiting. 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?

When both metrics end at delivery, the gap shows waiting before work starts. A large gap suggests intake queues or prioritization delays deserve attention. Cycle time can still include waits after work begins, so inspect workflow states before deciding where to intervene or which policy to change.

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. This keeps the math transparent and surfaces data quality issues early, before you automate reports.

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.

Pick one work item type. Start with production bugs or small features, not epics.
Pull the last 30 completed items.
For each item, capture four timestamps: request received, committed, start in progress, released.
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)
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. When you later layer in team velocity as a complementary signal, having clean lead and cycle time definitions keeps the numbers honest.

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 over time.

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.” Practices from lean-agile delivery are especially powerful here because they target waste, not heroics.

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. Limit active initiatives to a level the team can finish, then inspect the effect on flow.

Single-sentence reality check.

If accepted demand persistently exceeds delivery capacity, queues and customer wait times can grow.

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 struggle to split work may have unmanaged dependencies or difficulty meeting their Definition of Done in small increments. Address those constraints while preserving the quality standard. When you also adopt estimation techniques executives can trust, it becomes much easier to negotiate smaller slices without eroding stakeholder confidence. For deeper help, see our Mastering Backlog Refinement in complex product work guide.

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?

With the same completion boundary, lead time is at least as long as cycle time because it also includes waiting before work starts. If the measures use different endpoints, compare those definitions before interpreting the gap.

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. Techniques like WSJF-based prioritization can also help you decide which committed items should move first.

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. For data-heavy teams, the Data Product Owner Playbook shows how to connect these metrics from requirements to production.