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.
Industry Reality
- Most teams track cycle time informally at best. Jira has the data, but nobody pulls the reports — senior practitioners are often the ones who first introduce dashboards and make the metrics visible to the wider team.
- Lead time is quoted to stakeholders loosely and inconsistently. One PM defines it from backlog creation, another from sprint commitment — so cross-team comparisons are almost meaningless without agreeing on definitions first.
- Outlier items (blocked stories, scope-creep spikes) quietly inflate averages for weeks before anyone notices. High-performing teams remove or annotate outliers and use percentiles, not averages, for forecasts.
- In practice, organisations often confuse reducing cycle time with working faster. The real lever is reducing WIP and queue time — work that never starts cannot be delivered, and invisible queues are the norm in NZ SMEs where informal requests bypass any formal backlog process.
- Tooling varies widely: some teams use Jira's built-in Control Chart, others paste timestamps into a spreadsheet, and some rely entirely on gut feel. Whatever the tool, consistency of "start" and "done" definitions matters far more than the sophistication of the tool.
Context guide
How the right level of Cycle Time and Lead Time effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Government agency (e.g. Benefits NZ, Revenue NZ, CoverNZ) delivering citizen-facing services under ministerial scrutiny | Essential | Ministers and Select Committees want evidence-based delivery forecasts, not gut-feel estimates. Lead time data gives you defensible timelines; cycle time data shows where the bottleneck is when timelines slip. |
| NZ fintech or banking (Harbour Bank, Pacific Bank) running continuous delivery with compliance gates | Essential | RBNZ prudential requirements mean changes must be traceable and forecast accurately. Cycle time broken down by workflow stage exposes which compliance step (security review, CAB approval) is consuming the most time, enabling targeted process improvement without guessing. |
| Startup or scale-up with a small cross-functional team (under 10 people) | High | Informal request channels dominate in small NZ teams — features land via Slack, email, and word-of-mouth. Tracking lead time from the moment a request is logged makes invisible queues visible and forces the team to have prioritisation conversations before the backlog becomes unmanageable. |
| Large enterprise (TeleNZ, Pacific Air) with multiple squads and a shared backlog | High | With multiple squads sharing platform dependencies, queue time spikes when one squad blocks another. Per-squad cycle time dashboards expose inter-team wait times that would otherwise be hidden in sprint velocity numbers. |
| Early-stage project still defining its workflow and "Definition of Done" | Medium | Without stable start/done definitions, cycle time measurements are inconsistent and misleading. Focus on agreeing on workflow states first; introduce measurement after two sprints of stable practice so data is comparable. |
| Short-duration internal project (under 6 weeks) with a single deliverable | Low | Too few data points to draw meaningful trends. A scatterplot with 8 items tells you nothing statistically. Use a simple burndown instead and save cycle time metrics for the next project where you will have a sample large enough to act on. |
Trade-offs
What you gain and what you give up when you adopt Cycle Time and Lead Time.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Gives stakeholders objective, evidence-based delivery forecasts using p85 percentiles rather than developer estimates that quietly absorb padding. | Requires enough historical data to be meaningful — at least 15–20 completed items of similar type. Early in a project the numbers are noise. | Use story-point velocity instead when the project has fewer than three completed sprints and the team has no historical baseline to draw from. |
| Makes invisible queue time visible — the gap between lead time and cycle time directly points to upstream dysfunction (slow prioritisation, informal request channels) that velocity metrics never surface. | Teams can game the metric by moving cards to "In Progress" early, inflating active cycle time and making queue time appear shorter than it is — cultural discipline matters as much as the tooling. | Use a formal intake SLA (e.g., Kanban service classes) instead when the organisation wants to commit to queue time targets contractually rather than just observe them. |
| Separates customer-facing lead time from internal cycle time, enabling two distinct conversations — one with stakeholders about when they receive value, one with the team about where to improve process efficiency. | The two metrics require consistent definitions across the whole team and ideally enforced by tooling — if "done" means different things to different developers, cycle time data becomes incomparable across sprints. | Use throughput (items per week) as your primary flow metric instead when the team delivers many small, uniform items and stakeholders primarily care about volume rather than individual item latency. |
| Scatterplot variability is an early-warning signal — a widening spread appears weeks before average cycle time climbs, giving teams time to intervene before delivery commitments are at risk. | Without segmenting by item type (bug, feature, spike), the scatterplot mixes apples and oranges — a spike that takes three weeks looks like an outlier when it is actually expected, skewing the spread and triggering false alarms. | Use cumulative flow diagrams (CFD) alongside cycle time when you need to diagnose which specific workflow stage is accumulating the most work-in-progress, not just that cycle time is increasing overall. |
Enterprise reality
How cycle time and lead time tracking changes when you are operating across 200–300 developers at NZ banks, government agencies, or telcos
- At enterprise scale, cycle time measurement is automated via Jira Advanced Roadmaps or Azure DevOps Analytics — dashboards feed into real-time portfolio views used by delivery directors, replacing the manual spreadsheet-and-screenshot reporting that small teams rely on. Organisations like TeleNZ running 20+ squads cannot hand-curate this data; automated ingestion and normalised "started" definitions enforced at board configuration level are non-negotiable.
- Government agencies and banks must satisfy audit requirements that go beyond flow metrics. Under the New Zealand Information Security Manual (NZISM) and the Privacy Act 2020, change records must demonstrate traceability from request to production deployment — meaning lead time data doubles as an audit trail. At Revenue NZ, for example, lead time records for tax-system changes are retained and reviewable by the Office of the Auditor-General, so consistent, tooling-enforced timestamps are a compliance requirement, not a team preference.
- Volume-scale tooling introduces new bottlenecks that do not exist in small teams: Change Advisory Board (CAB) reviews, mandatory security scans (SAST/DAST), and multi-environment release trains can each add five to fifteen days to lead time while cycle time stays flat. CloudBooks, operating across Wellington and Auckland engineering hubs, segments lead time by workflow stage in their internal analytics platform specifically to distinguish "CAB queue" from "development active time" — without that segmentation, enterprise cycle time data is meaningless because the biggest delays are outside the squad's control.
- Coordinating cycle time targets across ten or more squads in multi-timezone delivery (common at TechServNZ and Pacific Air, which span NZ and offshore teams) means that a single squad's blocked story propagates downstream wait time to dependent squads, compounding lead time in ways that are invisible at the individual team level. Enterprise-scale QA leads must track inter-squad dependency lag as a separate metric alongside cycle time — otherwise the flow data looks healthy for each squad while the overall programme lead time blows out by weeks.
◆ What I would do
Professional judgement — when to adopt Cycle Time and Lead Time, when to adapt it, and what to watch for.
The bottom line: Cycle time is what you measure; lead time is what your stakeholders feel — and in NZ public-sector and regulated delivery, the gap between them is almost always political, not technical.
Best Practices
- ✓ Define "start" and "done" explicitly and document them in your team's working agreement — ambiguity here invalidates every measurement downstream.
- ✓ Segment cycle time by work item type (bug, feature, spike, chore) rather than averaging everything together; each type has a natural baseline and should be tracked separately.
- ✓ Use the 85th percentile for delivery forecasts, not the average — it gives stakeholders a realistic, evidence-based SLA and reduces the "why is it late again?" conversation.
- ✓ Track both cycle time and queue time together; a drop in cycle time that's accompanied by a spike in queue time usually means you've just moved the bottleneck, not removed it.
- ✓ Review the Control Chart scatterplot in every retrospective — a widening spread is an early warning of process instability, long before averages reveal the problem.
- ✓ Set a WIP limit that is lower than you're comfortable with and observe what happens; most teams discover their true bottleneck only after they stop starting new work.
- ✓ When cycle time creeps up, look at code review queue depth before blaming developers — review lag is the single most common hidden delay in software delivery.
- ✓ Present lead time to stakeholders and cycle time to the team; the two audiences need different numbers and conflating them leads to mistrust on both sides.
Common Misconceptions
❌ Myth: Cycle time and lead time are interchangeable — they both just measure "how long things take."
Reality: They measure fundamentally different things. Cycle time is a process efficiency metric (what your team controls); lead time is a customer experience metric (what your customer feels). Quoting cycle time when a stakeholder asks "when will I get it?" consistently over-promises delivery speed, because it ignores all the queue time before work starts.
❌ Myth: A lower average cycle time always means your team is performing better.
Reality: Average cycle time can drop while variability explodes — meaning some items still take weeks. A team that delivers most items in 2 days but regularly has 20-day outliers is less predictable than one delivering everything in a steady 5 days. Focus on reducing variability (tightening the spread) alongside reducing the average; predictability is what lets you make reliable commitments.
❌ Myth: Reducing cycle time means the team needs to work faster or put in more hours.
Reality: Cycle time is almost never limited by raw effort — it's limited by WIP, handoff delays, blocked items, and unclear requirements. Reducing WIP limits, improving code review turnaround, and breaking stories into smaller slices typically cuts cycle time by 30–50% with no increase in work hours. Telling a team to "go faster" without addressing these structural causes just increases stress without improving flow.
Senior engineer insight
Teams who genuinely understand cycle time and lead time distinguish between "why is delivery slow?" and "why does work sit in queues?"—and that distinction changes everything about where they intervene. The ones who do this well instrument their board from day one: they agree on a precise definition of "started" and "done," then review the Control Chart in every retrospective without waiting for a stakeholder complaint. The single pattern that actually moves the needle is segmenting cycle time by item type first—bugs, features, and spikes have different natural baselines, and blending them obscures every real signal.
The most common mistake teams make when adopting these metrics is quoting average cycle time to stakeholders as a delivery promise. The average hides the 15–20% of items that take two or three times longer, and those outliers are precisely the ones stakeholders will remember when commitments slip.
From the field
A Wellington fintech team running two-week sprints assumed their delivery problem was developer throughput—they were completing around eight stories per sprint and felt that was low. When a senior engineer finally pulled the Jira Control Chart, they found average cycle time was four days but average lead time was nineteen days: work was sitting in the backlog for three weeks before anyone touched it. The team had been optimising the wrong thing entirely, running refinement workshops to write better stories when the real fix was a WIP limit and a weekly prioritisation ceremony to drain the queue faster. After capping in-progress items at six and introducing a Monday triage slot, lead time dropped to nine days within six weeks—without a single extra hire or any change to development practice. The lesson that generalises: in NZ product teams where stakeholders submit requests informally through Slack and email, invisible queues are the rule, not the exception, and lead time is the only metric that makes them visible.
Self-Check
Click each question to reveal the answer.
Q1: What is the difference between lead time and cycle time?
Lead time measures from when a request is made to when it is delivered — the total duration including queue wait. Cycle time measures only the active work period, from when work is started to when it is completed. The difference between them is queue time: the period when the request was waiting before work began.
Q2: Which metric do customers feel and which metric does the team control?
Customers feel lead time — it answers "when will I get it?" and includes all waiting. The team controls cycle time — it reflects process efficiency within their own workflow. Both are important, but they serve different conversations: lead time for stakeholders, cycle time for the team.
Q3: A team has a high queue time but a short cycle time. What does this indicate?
Work sits waiting before it starts, but moves fast once it does. The bottleneck is upstream — slow backlog grooming, poor prioritisation, or insufficient resource allocation before work begins. The team's delivery process itself is healthy; the problem is getting work into that process.
Q4: Why should you use the 85th percentile for delivery forecasts instead of the average cycle time?
The average hides outliers. A team with an average cycle time of 5 days might have a p85 of 8 days — meaning 15% of work takes longer than 8 days. Committing to "5 days" based on the average means you'll regularly miss for normal items. The p85 gives stakeholders a realistic, evidence-based SLA with only a 15% chance of slipping.
Q5: What does a widening spread on a cycle time scatterplot tell you before the average reveals a problem?
It signals that the process is becoming less predictable — some items are taking much longer than usual even if the average hasn't moved yet. Widening variability is an early warning of instability, such as increasing WIP, blocked items piling up, or inconsistent story sizing. Catching this pattern early lets the team intervene before averages start climbing.
Q6: Your team is delivering a new online claims portal for CoverNZ. Stakeholders are asking "when will the bulk upload feature be ready?" Your average cycle time is 4 days but p85 is 9 days. How do you respond, and which metric do you quote?
A: Quote lead time for the stakeholder conversation, not cycle time — they care about total delivery time from request to production. Then use p85 as your forecast basis: "Historically, 85% of features similar in scope are delivered within 9 days of starting work; add any current queue time before the feature starts. I'd estimate 10–12 working days from now." Avoid quoting the 4-day average — it would imply a commitment you'll miss 15% of the time, which erodes trust when CoverNZ is tracking milestone dates for a government contract.
Q7: Your sprint team at TransitNZ is showing stable, short cycle times but stakeholders are still frustrated about long wait times for new features. Where should you investigate first, and what data would you look at?
A: Investigate queue time — the gap between lead time and cycle time. Short cycle time with frustrated stakeholders almost always means work is sitting in the backlog for weeks before the team touches it. Pull lead time data from Jira (creation date to completion date) alongside cycle time (in-progress date to done date). If lead time is consistently 3–4x cycle time, the bottleneck is upstream: feature requests are not being prioritised quickly, the backlog is too large, or informal requests from TransitNZ stakeholders are bypassing the formal backlog entirely and causing invisible queues.
Q8: What is the key difference between cycle time and throughput, and why can improving one make the other worse if you are not careful?
A: Cycle time measures how long each individual item takes from start to done. Throughput measures how many items are completed per unit of time (e.g., per week). They are related but not the same: when WIP is stable, higher throughput usually correlates with lower cycle time. However, if you artificially reduce cycle time by starting more work in parallel — pulling items into "In Progress" to look busy — WIP rises, context-switching increases, and each individual item actually takes longer. Throughput appears to rise briefly but then drops as the system gets congested. The safer path is to reduce WIP limits first, which stabilises cycle time and then naturally increases throughput.
Q9: A developer on your Revenue NZ tax-filing project says, "Cycle time is creeping up because the testers are slow — we need more testers." What is wrong with this reasoning and how do you investigate it properly?
A: This assumes the bottleneck is in testing without looking at the data. Before adding headcount, segment cycle time by workflow stage: check how long items spend in development, in code review, waiting for test, and in testing. In practice, the most common hidden delay is code review lag — items sitting in the review queue for days before a tester ever sees them. If code review queue depth has grown while test cycle time is flat, adding testers solves nothing and wastes budget. Pull the Jira Control Chart or a simple spreadsheet of state-transition timestamps, identify which stage items spend the most time in, and address the actual bottleneck. Only recommend more testers if test cycle time specifically is the outlier.
Why teams fail here
- Defining "started" inconsistently across the team — one developer moves cards to In Progress when they pick them up, another when they first commit code, making cycle time measurements incomparable across stories and sprints.
- Ignoring queue time entirely and treating cycle time as the only flow metric — this makes the team look efficient while lead time balloons, leaving stakeholders frustrated for reasons the team cannot see in their own data.
- Using average cycle time for delivery forecasts instead of p85 or p95 — averages are systematically optimistic because the slowest items (blocked stories, scope-creep spikes) drag real delivery dates without raising the average much until many have accumulated.
- Comparing cycle time across teams without agreeing on definitions first — different boards, different "done" columns, and different work item sizing mean the numbers are apples and oranges, and cross-team comparisons breed resentment rather than insight.
Key takeaway
Cycle time and lead time done well are not reporting tools—they are diagnostic instruments that tell you exactly where in your system work is stuck, so you can fix the process rather than pressure the people.
How this has changed
The field moved. Here is how Cycle Time & Lead Time evolved from its origins to current practice.
Cycle time and lead time originate in manufacturing — Toyota Production System defines cycle time as time to complete one unit, lead time as total time from customer order to delivery.
David Anderson formalises cycle time and lead time as the primary delivery metrics for software Kanban teams. Cycle time (started to done) and lead time (requested to done) replace velocity as the key flow measures.
Agile analytics tools begin providing automated cycle time and lead time distributions from Jira. Teams move from average metrics to percentile-based — "90% of stories done in under 5 days" is more useful than "average is 3 days."
DORA metrics include lead time for changes as one of four key engineering performance indicators. Lead time correlates with organisational performance — elite teams have lead times under 1 day.
AI-powered flow analytics predict delivery dates from cycle time distributions using Monte Carlo simulation, without requiring story point estimation. Teams are shifting from estimation-based planning to flow-based forecasting.