Glossary
Lead time and cycle time: the difference
Lead time starts when the request appears, cycle time when work begins. Why confusing them is expensive, and what to do with the numbers.
Lead time measures from the moment a request appears until it is finished. Cycle time measures only the span in which it was actually being worked on. The difference is waiting — and waiting is usually the larger part.
Why the distinction matters
Because they answer different questions. Cycle time says something about the work; lead time says what the customer experiences. A team can halve its cycle time, and if requests sit in the backlog for three weeks first, nobody outside notices any difference.
What to do with them
Not set targets — find queues. If cycle time rises while the work has not got bigger, the team is running too much in parallel, and a WIP limit is the answer. If lead time is high while cycle time is low, the problem is not delivery but what happens before it.
Compared with velocity
Velocity measures volume per iteration and only works with sprints. Lead and cycle time need no iteration, which is why they are the metrics of choice for Kanban teams.
FAQ
When does cycle time start?
When somebody actually begins — usually the move into the "in progress" column. What matters is defining that point the same way every time.
Which one should we track?
Both, but for different questions: cycle time for how you work, lead time for what the outside world experiences.
Is a short lead time always better?
Not at any cost. You can shorten it by accepting less or working sloppily, which is why it is read alongside quality and volume rather than alone.