Lead Time vs Cycle Time
Two closely related flow metrics — lead time measures from customer request to delivery; cycle time measures from active work start to delivery.
Definitions
Lead time is the elapsed clock time from when a customer request enters the system to when it is delivered. Cycle time is the elapsed clock time from when the team actively starts work on it to delivery. The difference is queue time — the time the request sat in a backlog before someone started on it. Both metrics are indispensable to any team trying to run a flow-based operating model, whether that is a Kanban software team, a DevOps platform team, or a construction procurement group.
Why Both Matter
Customers experience lead time. If a client raises a support ticket and it takes 22 days to close, they do not care whether the team spent 21 days ignoring it and one day fixing it, or one day ignoring it and 21 days fixing it. Both are equally painful. Cycle time, on the other hand, is what the team controls. It is the honest measure of the team's throughput once they start. Measuring only one distorts the picture: cycle-time-only teams miss that they are hiding queue time; lead-time-only teams cannot tell whether they need to work faster or intake less.
Real-World IT / Agile Example
A platform-engineering team reported average cycle time of 6 days and was proud of it. When they finally added lead-time tracking, the number came back at 38 days. The queue in front of the team was six times longer than the work itself. The response was not to hire more engineers — it was to introduce a WIP limit on the queue and a bi-weekly conversation with product about which requests actually needed to enter the system. Six months later: lead time 11 days, cycle time still 6 days. The team did not work faster; they queued less.
Real-World Construction Example
A precast fabrication yard tracked lead time and cycle time for structural elements. Lead time (order to delivery): 62 days on average. Cycle time (start of moulding to delivery): 11 days. The 51-day gap was almost entirely design-approval queue. The client's engineer took an average of 34 days to approve shop drawings. Once that queue was made visible, the client set an internal five-day SLA. Lead time dropped to 27 days without changing anything in the fabrication yard. The same lesson: measure both, act on the bigger one.
Distributions, Not Averages
- Averages hide skew. Most work items follow a lognormal distribution — many are fast, a few are catastrophic.
- Report the 50th, 85th, and 95th percentiles.
- Use the 85th percentile for delivery forecasts to customers — it is more honest than the average.
- Watch the tail. A 95th percentile that keeps growing while the average is stable means outliers are getting worse, and outliers destroy trust.
Expert Tips
- Instrument at the workflow level, not the ticket level. Timestamp when items move between states (backlog → in progress → review → done).
- Publish both metrics. Customers should see lead time; the team should see both.
- Forecast with percentiles. "85% of items complete in under 12 days" is more useful than "average 6 days" for planning.
- Correlate with WIP. Little's Law: lead time = WIP / throughput. Reducing WIP is the fastest way to cut lead time.
- Break down by class of service. Expedite items behave differently from standard items; averaging them together hides the story.
Common Mistakes
- Reporting only average cycle time and celebrating it.
- Ignoring queue time as "not the team's problem" — it is the customer's problem, which makes it the team's.
- Adding engineers to a backlog problem — usually queues are governance issues, not capacity issues.
- Not defining "start" and "end" consistently — different tools mean different metrics, so numbers cannot be compared.
- Chasing shorter cycle time by cutting scope of work items until they are meaningless.
Practical Lessons Learned
- In most teams I have coached, cutting lead time by half comes from reducing intake or WIP, not from working faster.
- The single most effective governance intervention is a monthly review of the queue: what is old, what is stale, what should be closed as no-longer-relevant.
- Teams that share their percentiles with stakeholders build trust; teams that hide behind averages generate friction every quarter.
Key Takeaways
- Lead time = customer's experience; cycle time = team's throughput.
- The gap is queue time — usually the largest lever for improvement.
- Report percentiles, not averages.
- Little's Law: reducing WIP directly reduces lead time.
Related Encyclopedia Entries
Related Research Articles, Case Studies & Tools
Frequently Asked Questions
Is cycle time the same as throughput?
No. Cycle time is the elapsed time per item; throughput is the number of items completed per period. They are related by Little's Law but they measure different things — a team with high throughput can still have long cycle times if it is running with too much WIP.What is a 'good' cycle time?
There is no universal number — it depends on item size and domain. A useful heuristic: 85th percentile under two sprints for a software team, under one week for a DevOps ticket, under two weeks for a construction procurement request. Trend matters more than absolute value.Should I include weekends in cycle time?
Include calendar days if you report lead time to customers (they experience weekends). Some teams also track a 'working-day' cycle time internally to identify process problems. Pick one, be consistent, and label it clearly.Why is my average so different from my median?
Because item size distributions are almost always right-skewed. A few catastrophic outliers pull the average far above the median. The median (50th percentile) is a more honest single number for typical performance.How does this apply outside software?
Any workflow with a queue and active work has both metrics. Construction procurement, hospital patient flow, manufacturing, legal drafting — all benefit from separating queue time from active work time.How do I reduce lead time without adding people?
Reduce WIP, reduce intake (say no to lower-value items), split larger items, and remove non-value-add steps. Adding people to a queue problem often makes it worse in the short term.Do these metrics work at portfolio level?
Yes but with care — portfolio items are large and rare, so you need many months of data before percentiles become meaningful. Team-level metrics are more actionable; portfolio-level metrics are strategic and slower.What is a common misconception about Lead Time vs Cycle Time?
That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.Which related encyclopedia entries should I read alongside Lead Time vs Cycle Time?
Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.How does Dr. Hassan Eliwa's research treat Lead Time vs Cycle Time?
Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Lead Time vs Cycle Time is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.How is Lead Time vs Cycle Time defined on PMMilestone Research & Insights?
Two closely related flow metrics — lead time measures from customer request to delivery; cycle time measures from active work start to delivery. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.
People also ask
Follow-up questions practitioners search for next — each one points to the calculator, template or reference entry that answers it.
Where is this in the glossary?
Quick-lookup definitions across 1,200+ PM terms. PM Glossary on PMMilestone.org ↗
Which learning track covers this end-to-end?
Structured tracks from beginner planner to programme controls director. Project Controls Academy ↗
Which book goes deeper than this entry?
Practitioner field handbooks with worked numerical examples. Books & Publications ↗
Which calculator on PMMilestone.org applies here?
The integrated EVM workbook covers most cost-schedule diagnostics. EVM Calculator ↗
Related Entries
More in Agile
- Letter AAcceptance Criteria
The specific, testable conditions a deliverable must meet before the customer accepts it — the contract between a team and the person who will sign off the work.
- Letter BBacklog Refinement
The ongoing practice of clarifying, splitting, estimating, and ordering items on a product backlog so the team always has a healthy queue of ready work for upcoming sprints or releases.
- Letter BBurn-Down Chart
A time-series chart showing remaining work against time, used by agile teams to visualise sprint or release progress and forecast completion.
- Letter CContinuous Integration
The engineering practice of merging code changes into a shared mainline many times a day and verifying each merge with automated builds and tests.
- Letter CCumulative Flow Diagram
A stacked-area chart of work items in each stage over time — the single most informative chart in lean and Kanban flow management.
- Letter DDaily Stand-up
A short, focused, time-boxed daily meeting where the delivery team aligns on progress, plans the next 24 hours of work, and surfaces blockers.
Further reading on PMMilestone.org
Curated companion resources hosted on the flagship platform, PMMilestone.org.
- For practitioners who want to go deeper, the Learning Tracks.
- Engineers researching this topic typically continue with the Books & Publications.
- A practical companion to this entry is the EVM Calculator.
- Closely related on the flagship platform is the Schedule Health Checker.
- Useful alongside this article is the PMMilestone.org knowledge hub.