Short answer: Cycle time is how long a story takes from when work starts to when it's done. Lead time is how long it takes from when the story is filed to when it's done — including the time it sat in the backlog waiting. Most teams confuse them and measure only cycle time, then wonder why customers say the team is slow. The number that predicts delivery is cycle time; the number that predicts customer perception is lead time.
The cycle time refers to the duration it takes to finish a story once work starts. Lead time refers to the time from filing a story to its completion. What distinguishes the two stories is the time spent in the backlog before anyone touched it.
Cycle times refer to how long it takes to complete a story, once work gets started. It matters because a team can be fast in its cycle times the story can be completed quickly once work starts on it but have bad lead times. This is because the story sits in the backlog not being started on for weeks, hence its lead time is horrible. Customers encounter lead time. Cycle time reflects the pride of engineers. A team focused solely on cycle time will speed up the creation of inappropriate items while one focused solely on lead time will bolt flat out on the wrong queue.
This guide explains what is actually being measured by each metric, why they get confused, how to compute them honestly, which one to use for which decision and the most common reporting mistake. Engineering managers, anchors, and PMs attempting to interpret flow metrics. For a wider treatment of the same two metrics outside Lean, Martin Fowler's note on lead time is the cleanest source.
What each actually measures
The point at which the work is done (accepted, shipped, closed etc) is the same for both cycle time and lead time.
The timing of the clock is the difference.
| Metric | Clock starts | Clock ends | Includes time in backlog? |
|---|---|---|---|
| Lead time | When the story is filed / requested | When it's Done | Yes |
| Cycle time | When work begins (typically: moved to "In Progress") | When it's Done | No |
An exemplary guide. On Monday, a bug is reported. The team is preoccupied with their other sprint tasks and leaves it until two weeks later, Monday week 3. Engineer picks it up Monday and Tuesday and ships Wednesday morning.
- Lead time: 16 days (Monday filed → Wednesday of week 3 done).
- Cycle time: 3 days (Monday of week 3 started → Wednesday done).
Similar job. Similar consequence. Two distinct numbers. If the only information reported by the team is “cycle time = 3 days”, a stakeholder wondering why it took 16 days to fix that bug will be confused. Both numbers are required.
Why teams confuse them
Three Common Causes
- The tool only tracks one. Many agile boards count from "In Progress" to "Done" by default, which produces cycle time and silently drops lead time. Teams report what the tool shows.
- The definition of "started" is fuzzy. If "In Progress" means "I've added it to my sprint" rather than "I've actively begun coding", cycle time creeps toward lead time, and the distinction blurs.
- The literature uses both terms inconsistently. Some sources define lead time as "code committed to deployed" (a totally different thing). Others reverse the labels. Pick a definition and stick to it on your team; the words are less important than the consistency.
The Lean and Kanban traditions employ the definitions in the table above – lead time = customer-experience metric (from request to delivery) and cycle time = team-execution metric (from start to delivery). See the Kanban Guides and Atlassian's overview of agile metrics for the same convention spelled out differently. Modern agile advice is converging on those definitions.
How to compute them honestly
Each story requires two timestamps, a “start” timestamp and a “done” timestamp, for both metrics. Most trackers automatically track these events if you have set your workflow with distinct state transitions; the LiteTracker cycle time report example using the API walks through pulling the raw timestamps yourself.
For every completed story across a window (last 4 weeks, last quarter, last release).
- Lead time: done_at − filed_at.
- Cycle time: done_at − started_at.
Use the median and 85th percentile for aggregation The distribution of story completion time has a right skew as there are a few stories that take significantly longer than others, and weekend gaps inflate raw deltas in ways that excluding weekends from cycle time helps correct for. The mean Get Shit Done time is impacted by these outliers and thus is not the best measure of central tendency. The median gives the usual situation whereas the 85th percentile gives the worst case to plan for. The mean solely provides insight about outliers in the data.
| Statistic | What it tells you |
|---|---|
| Median lead time | The customer experience for a typical request |
| 85th percentile lead time | The customer experience for a slow request |
| Median cycle time | The team's typical execution speed |
| 85th percentile cycle time | The team's worst-case execution |
| Mean | The shape of your outlier tail (only useful for comparison) |
When we report both lead time and cycle time at both the median and 85th percentile, we’ll end up with four numbers. This sounds like a lot, but each one tells you something different and together the four is enough to diagnose almost every flow problem.
Which to use for which decision
These two metrics resolve different queries.
- "Are we shipping fast enough for customers?" → Lead time. If users wait 30 days from filing a bug to seeing it fixed, the experience is bad regardless of how fast your sprints run.
- "Are we executing efficiently once we start?" → Cycle time. Long cycle times mean stories are too big, dependencies block work, or the team has too much WIP.
- "Can we forecast delivery?" → Cycle time, with caveats. A predictable cycle time means you can promise reliably; a predictable lead time depends on backlog discipline too, since unrefined stories distort the front of the queue. Teams that lean into predictability over velocity get more useful forecasts than teams chasing a higher number.
- "Where's the bottleneck?" → Look at the gap between lead time and cycle time. Big gap = backlog sits too long. Small gap = the bottleneck is in execution.
- "Are we doing too much WIP?" → Cycle time. WIP increases cycle time linearly (Little's Law: WIP = throughput × cycle time).
When stories are smaller, cycle times drop from days to hours and teams reach users up to 14× faster. This doesn’t happen by exhortation it happens by cutting WIP, splitting stories more aggressively, and removing the dependencies that are responsible for long tail cycle times. The numeric indication directs your attention; the labor pertains to structure.
The most common reporting mistake
With enough reviews, a pattern emerges: The team shows a cycle time chart with a lot of confidence. The stakeholders ask why a certain story took two months. Nobody can explain it because the charts have hidden the backlog wait.
It is a mistake to only report cycle time. Both are reported together with a gap visible. If the lead time is 30 days and the cycle time is 3 days, the backlog discipline is the problem, not the team. Execution is the problem if lead time (30 days) is greater than cycle time (28 days).
Another pattern is averaging across all types of stories. While a 2-point bug fix and 13-point migration may have significantly different cycle times, averaging their cycle times tells you about your portfolio mix, not your overall speed. Prior to averaging, segment by story size or take median of the smallest story size bucket (this is what team is shipping often).
Another approach is to count the time between the start of one sprints and the start of the next. What is needed is not the cycle time but "sprint duration with extra steps". The cycle time is at the per-story level using actual story timestamps, not sprint calendar dates — the same trap that turns velocity into a measure of pace, not productivity.
When the metrics aren't worth measuring
Lead time and cycle time are not free. They require discipline to ensue the intended workflow state transitions, time to report inputs, and team energy to argue on what the numbers actually mean.
- Team of two. The metric isn't telling you anything you don't already know. Skip.
- Pre-product-market-fit. The variance of work is so high that the numbers are noise. Skip until the team is shipping similar-shaped stories iteration after iteration.
- Pure operations / on-call rotations. Incident response has its own metrics (time-to-detect, time-to-resolve); flow metrics don't apply.
- The team is gaming the metric. If "cycle time" is on a dashboard somebody is judged against, expect to see "In Progress" pushed late and "Done" pushed early. The number stops meaning anything. Either de-emphasise the dashboard or accept that the metric is now a target, not a measurement.
For all others: track both metrics, communicate both metrics, address the gap's bottleneck, and let process data — not gut feel — guide the conversation.
When NOT to chase lower numbers
A genuine viewpoint that opposes popular Kanban recommendations: lower isn’t always better.
A two-hour cycle time sounds great until you realise the team is shipping tiny, decontextualised changes that don’t compose into user value. An impressive one-day lead times is meaningless if the backlog is empty because the team shuffles every request along with no prioritisation.
Targets that are right.
- Cycle time stable and roughly predictable, with a 85th percentile not much above the median (small variance).
- Lead time in a range customers find acceptable for the kind of work — usually days for bugs, weeks for features, quarters for major work — with the same variance discipline.
When a team is focused on reducing cycle time, they game the system. A team whose goal is stable predictable numbers with low variance ships consistently, which is what the customer wants.
Frequently asked
What's the difference between lead time and cycle time?
Cycle time is how much time a piece of work takes once it starts. The duration from the moment it is filed to being Done, including time spent in the backlog. Similar goal, different beginnings. Cycle Time is a metric for the Team, Lead Time is for the Customer.
Which metric matters more?
They both answer different questions. The cycle time gives insight into the speed of execution, while lead time speaks to customer experience. By observing the gap between the two, it reveals whether the issue lies with the team's execution or with creating order in the backlog.
How do I measure cycle time in agile?
For every story: complete_at subtracted from begin_at. Use Median & 85th Percentile to Aggregate across Your Stories.
Should I use mean or median for cycle time?
Median. The distributions of cycle times have a right skew, with averages pulled upward by outliers. The median gives you the standard outcome; the 85th percentile indicates your least favourable situation you ought to factor. The mean is only helpful when comparing tail shape.
How does cycle time relate to WIP?
WIP is calculated using throughput and cycle time by Little’s Law. Maintain a steady throughput, and the WIP will increase in a linear fashion. Shrinking the work-in-progress or limiting the number of stories in-progress is the fastest way to reduce cycle time, not pushing the team to go faster.
Is sprint duration the same as cycle time?
no The sprint duration concerns the calendar window in which work happens, while cycle time concerns a per-story measure. It is measured from state transitions that actually happen. You can have stories with cycle times in hours and time to the sprint in a two-week sprint.
What's a good cycle time for software stories?
Based on story size and team size. A small story should typically have a median cycle time under a few days while a larger story may take a sprint or more. It is more essential for something to stable than have great variation. The gap between the median and the 85th percentile is more essential than the absolute number.
Does lead time include backlog refinement?
Absolutely, lead time begins at the moment of request submission and concludes upon marking it done, irrespective of any intermediary events. As for examples, if the story sat in backlog for two weeks then went through refinement, that all counts. Lead time is from the customer’s view, and the customer does not care that you were grooming.
Still stuck
If you consistently measure both lead time and cycle time at the median and 85th percentile and can identify the bottleneck that these measurements reveal, I think you have the discipline. Most disagreements teams have about flow metrics are about which number to put on a dashboard the real decision-making power is in looking at the gap, not the number alone.
LiteTracker is your tool if you want to automatically record state transitions and surface both metrics, all without configuration. Anyone can use it for free. However, do not use it if you have less than three engineers; the metric noise will be more than the signal at that scale.
In any case, report both and disregard the average.