Cycle Time vs Lead Time: The Difference and Why Both Matter
By Sebastiaan Jansen · · 7 min read
Cycle time vs lead time comes down to two waits: how long the customer waited, and how long the team spent once work actually started. Lead time runs from the moment a request arrives until the result is delivered. Cycle time runs from the moment someone starts that request until the same delivery, so it leaves out the queue that built up before anyone touched it.
Both clocks measure elapsed time, not effort hours. Six hours of typing can still show up as five days once you add nights, reviews and waiting. If you mix the two up, you end up "fixing" a chart the customer never sees.
Cycle time vs lead time, side by side
Lead time and cycle time share a finish line but disagree about where the race starts. Use the same unit for both (calendar days or business days) and the same definition of done, or subtracting one from the other gives you noise.
| Lead time | Cycle time | |
|---|---|---|
| Starts | Request arrives | Someone starts the work |
| Ends | Delivered, by your written policy | The same delivery point |
| Includes the queue before anyone starts | Yes | No |
| Includes waiting after start (review, test, blocked) | Yes | Yes |
| Question it answers | How long did the requester wait? | How long did this take once we picked it up? |
A ticket filed Monday and shipped Friday has four days of lead time. If it moved to In Progress on Wednesday, cycle time is two days. The difference is queue time, and cycle time on its own hides it.
Pick one arrival and one done. "Created", "a chat turned into a ticket" and "accepted into this sprint" are three different starts. Merged, deployed and accepted by the requester are three different ends. A clock that starts at sprint start has already thrown away the backlog, and two different finishes on one chart will look like a process problem when they aren't.
What each clock contains
Lead time is the requester's wait
Lead time starts when the request exists, so it covers triage, approval, the backlog, active work and rework. A long lead time next to a short cycle time means the days are piling up before "start." Adding work in progress won't shrink that queue. Fewer arrivals, faster intake, or a deliberate choice about what starts will.
Cycle time is time after start, not touch time
Cycle time starts at the first move into the active state and ends at the same done state as lead time. Review, test, blocked time and deploy waits all still count. That makes it different from touch time: two days of cycle time can be ninety minutes of work and a long wait in the review queue.
Why there is no universal "good" number is covered in cycle time in software development. This piece only draws the line between the two clocks.
The formulas
Work from timestamps:
- Lead time = delivery time minus arrival time
- Cycle time = delivery time minus start time
- Queue before start = lead time minus cycle time
The third line only holds when both clocks share a finish and a calendar, so convert both into one unit before you subtract.
Use percentiles rather than an average. p50 is the typical item; p85 is a result you beat about fifteen times in a hundred. An average of three days can hide a tail at twenty. Whenever you quote a number, name the ticket type, the period and the calendar with it.
A worked example
"Add export on the billing page" is an illustration, not a benchmark. It was logged Monday 09:00 (lead time starts) and sat in triage until Wednesday 11:00 (cycle time starts). It was built Wednesday, reviewed Thursday and deployed Friday 15:00.
Lead time is 4 days and 6 hours. Cycle time is 2 days and 4 hours. About 2 days and 2 hours passed before anyone started.
If the team had started at 09:00 instead of 11:00, cycle time would grow and lead time would stay put. The chart looks worse, and the client still gets the export on Friday. If triage had finished Monday afternoon, only lead time would drop, and that's the change the client actually feels.
Compare a same-week copy fix that came in at 10:00, started at 10:30 and was done at 16:00: 6 hours of lead time and 5.5 of cycle time. Average it with the export and the figure describes neither ticket. To forecast the next export, look at similar items.
Why you need both
A long cycle time points to too much work in progress, a review column nobody owns, items that are too big, or a finish rule nobody wrote down. The fixes are smaller slices, fewer handoffs and WIP limits.
A long lead time beside a short cycle time points to intake, approval, and a backlog ordered by whoever spoke last. Starting more work usually stretches both clocks. If the gap widens, items are waiting longer before they start. If the gap shrinks while cycle time rises, you pulled work forward and the pipeline absorbed the queue. A single velocity number blurs those two situations together.
Give a requester the lead time for one ticket type over a named period, and give the team its cycle time for the week. A launch date needs lead time, because the date includes the queue. See launch dates you can plan against.
Cycle time can also fall simply because the tiny tickets finished while the large ones kept aging. Throughput is how many items finished. Read throughput and cycle time together before you call the system faster.
Lead time in agile
Lead time in agile is not a Scrum ceremony, and the Scrum Guide defines neither clock. A story can sit for weeks and then spend three days in a sprint, and the burndown only shows the sprint.
Story points estimate effort, while these clocks measure elapsed time. Twenty days of waiting costs the same whether the item is large or small. DORA's "lead time for changes" runs from commit to production rather than from request to delivery, so keep it in its own column.
What usually stretches each number
Lead time grows when untyped requests go back through triage, when one approver blocks every start, when work waits for the next sprint, and when one title turns out to be three projects.
Cycle time grows with too much in progress, a review or test column nobody owns, a finish rule that only lived in someone's head, and blocked items that stay "active" through the weekend.
Counting weekends matches how a Friday-to-Monday wait feels to the requester. Skipping them makes it look like one day. Whichever you choose, write the policy on the chart. Keep an eye on aging work too: finished cycle time can look calm while three tickets have been active for a month.
Reading the pair with the rest of the board
For cycle time vs lead time, cumulative flow is where you see the gap forming. If arrivals climb and done stays flat, later lead times will rise even while this week's finished tickets still show a short cycle time. How to read a cumulative flow diagram walks through that picture.
For a date, sample the distribution. A Monte Carlo forecast draws from finished lead times, or from throughput, and reports how often a given scope lands by a given day. A couple of thousand runs is normal. The history you feed it matters more than the run count, and it should be one ticket type at a time, because incidents, copy fixes and multi-team projects don't share a distribution. The method is in Monte Carlo forecasting for software delivery dates.
Any board with arrival, start and done timestamps can compute the pair, as long as you use one start state and one done state and keep incidents off the feature chart.
Falrow computes cycle time percentiles, cumulative flow and Monte Carlo forecasts from that history, and starts lead time when call notes become reviewed tickets. Jira, Linear and Azure DevOps report parts of the pair. When you compare tools, check whether you can see a high percentile of each clock for one ticket type without a side export. Those views are under cycle time, cumulative flow, and Monte Carlo forecasts.
FAQ
Is cycle time always shorter than lead time?
Yes, as long as both share a finish and cycle time starts at the same moment or later. If cycle time looks longer, the timestamps or done states don't match, and you should fix that first. If work starts the moment it arrives, the two numbers are equal and the queue is zero.
Can lead time and cycle time be the same number?
They match when start and arrival are the same event. That's common for an interrupt and rare on a shared backlog. Equal numbers only tell you nobody waited before the first touch. A six-week item started the minute it was filed is still slow.
Should we use business days or calendar days?
Use the calendar the requester feels, and label it. Calendar days match "by Friday" across a weekend, while business days make Friday-to-Monday look short. Don't mix units, and check which calendar a borrowed target used.
Which one should we try to shorten first?
Pick one ticket type over a recent month and check the gap. A long cycle time sits inside the active system: too much in progress, items that are too large, or a wait in review and test. A short cycle time with a long lead time is an intake problem. Shortening the smaller clock won't move the date the requester sees.