Cycle time and lead time get used interchangeably constantly — in blog posts, in tool documentation, sometimes inside the same paragraph. They're not the same measurement, and the gap between them isn't pedantic: it's the difference between "how fast the team works" and "how long the customer actually waits," and mixing them up produces a forecast that's technically calculated correctly and still answers the wrong question.
Lead time: the customer's clock
Lead time starts when a piece of work is requested — created as a ticket, added to the backlog, however a team marks "this is now a thing we've agreed to do" — and ends when it's delivered. It's the total wait, including every day the ticket sat untouched before anyone picked it up. If a client asks "how long did this take from when I asked for it," lead time is the honest answer, because it includes the queue.
Cycle time: the team's clock
Cycle time starts when work actually begins — a ticket is pulled into an active, in-progress state — and ends when it's done. It excludes backlog dwell time entirely. Two tickets with wildly different lead times (one sat in the backlog for three weeks, one got picked up same-day) can have identical cycle times if the team spent the same four days of active work on each. Cycle time measures the team's own processing speed, isolated from how long anything waited in line first.
Where most explanations quietly go wrong
The definitions above sound clean. The actual disagreement in most write-ups isn't the definitions — it's that they skip specifying exactly where each clock starts and stops, and that's where two teams can compute "the same metric" and get genuinely different numbers. A few concrete ambiguities that get glossed over constantly:
Does lead time start when a customer first asks, or when the ticket is formally accepted into the backlog? Those can be weeks apart if there's an intake or triage step, and plenty of explanations use "request" and "backlog entry" as if they're the same moment.
Does cycle time start the moment a ticket is marked "Selected for Development," or only once someone is actually, physically working on it? A ticket sitting in "Selected for Development" for four days before anyone touches it is backlog dwell time wearing an in-progress-sounding label — counting it as cycle time quietly inflates the number and hides a real queueing problem behind what looks like slow execution.
And a subtler one, inherited from cycle time's manufacturing origins: in classic operations-research usage, "cycle time" sometimes refers to the rate at which units complete (effectively the inverse of throughput), not the elapsed time a single unit spends in process. Software teams borrowed the term to mean the latter — time-in-progress per ticket — which is standard Kanban usage today, but it's worth knowing the word has a different meaning one field over, because it's part of why online explanations don't always agree with each other.
None of this makes the concepts complicated. It just means the fix isn't "learn the right definition" — it's "pick a specific column boundary and write it down," the same way a board's columns need an explicit backlog/in-progress/done boundary before cycle time means anything consistent across tickets.
Why this matters for a forecast
A Monte Carlo forecast for "when will the remaining backlog be done" should be built on cycle time, not lead time — it's simulating how fast the team processes work once picked up, combined with how much is in progress at once (WIP), not how long tickets have historically sat waiting before anyone started them. Feed a simulation lead-time data instead, and a long-ago intake bottleneck that's since been fixed will still be dragging the forecast toward a later date than the team's current, actual pace justifies.
Lead time still matters — just for a different question. If a client asks how long they've been waiting on a specific request, lead time is the number that answers it honestly, queue and all. The two metrics aren't competing for the same job; using the wrong one for either job is what causes the trouble.