Lead time is how long a card takes from the moment someone asks for it to the moment it is finished. Cycle time is how long it takes from the moment work starts to the moment it is finished. The gap between the two is waiting time, the days a card spent in the backlog or stuck in a queue while nobody touched it. Lead time is what the person who asked experiences, and cycle time is what the team controls.
Most explanations of lead time vs cycle time stay at the level of a definition and a car repair analogy. This one uses a real board with real dates, shows how to read both numbers off it, and covers the part that causes arguments: not every source defines these words the same way.
What is lead time on a kanban board?
Lead time starts the day a card is created, or the day the request reached you, and ends the day it lands in your last column. Everything in between counts, including the weeks a card sat in "Backlog" before anyone looked at it.
That is why lead time is the number a customer or colleague cares about. They do not know or care whether your team was busy on something else. They asked on the first, they got it on the ninth, and the answer to "how long did that take?" is eight days.
What is cycle time on a kanban board?
Cycle time starts the day a card moves into your first active column (often "Doing") and ends the day it is finished. A card that waits in the backlog for a month and then takes two days to do has a cycle time of two days.
Cycle time is the number a team can improve on its own, because it only measures the part of the trip the team owns. It is also the one that tells you how long to promise the next request, once you have a few weeks of it. If you want the full set of flow numbers, kanban metrics explained covers cycle time alongside throughput and work item age.
How do lead time and cycle time differ?
| Lead time | Cycle time | |
|---|---|---|
| Clock starts | Card is requested or created | Work on the card begins |
| Clock stops | Card is finished | Card is finished |
| Includes backlog waiting | Yes | No |
| Who feels it | The person who asked | The team doing the work |
| What it tells you | How long people wait | How long work takes |
The relationship is simple: lead time is cycle time plus the time the card waited before work began. If the two numbers are close, cards are picked up quickly. If lead time is far larger, the delay is in the queue and not in the work.
What does it look like with real dates?
Take five cards from a small board. Each row shows when the card was added, when it moved into "Doing" and when it was finished.
| Card | Added | Started | Finished | Lead time | Cycle time |
|---|---|---|---|---|---|
| Fix invoice template | Oct 1 | Oct 6 | Oct 8 | 7 days | 2 days |
| Write onboarding email | Oct 1 | Oct 2 | Oct 9 | 8 days | 7 days |
| Update pricing page | Oct 2 | Oct 9 | Oct 10 | 8 days | 1 day |
| Plan webinar | Oct 3 | Oct 6 | Oct 15 | 12 days | 9 days |
| Renew domain | Oct 6 | Oct 7 | Oct 8 | 2 days | 1 day |
Lead time is the finish date minus the added date. Cycle time is the finish date minus the start date. Across these cards the average lead time is 7.4 days and the average cycle time is 4 days, so the average card waited 3.4 days before anyone started it.
Two things are worth noticing. The pricing page took one day of work but its requester waited eight, so the delay was entirely in the queue. The webinar plan is the opposite: it started almost at once and then dragged, which is a problem with the work itself.
Should you use the average or the middle value?
Use the middle value (the median) as well as the average, because one slow card pulls an average up. Here the median cycle time is 2 days, against an average of 4, because the webinar and the onboarding email stretch the mean while three cards finished in two days or fewer.
If you only quote the average, you will promise a delivery time that most cards beat comfortably and a few badly miss. A better habit is to say that most cards finish within a range, and to look at the slow ones one at a time. A card that is far over your usual range is a prompt to ask what blocked it, which is also what work item age is for while the card is still open.
Why do different sources define cycle time differently?
Because the word was borrowed from manufacturing, where it had other meanings, and software writers then used it in more than one way. In lean manufacturing, cycle time can mean the interval between finished units coming off a line. In many kanban books and tools it means time in progress for a single item. Some authors use it for the whole request-to-delivery span, which is what this post calls lead time.
One long write-up of the clash shows well-known books disagreeing with each other. The practical lesson is small. When someone quotes a number, ask which two events it sits between. If your team writes down "starts when the card enters Doing, ends when it enters Done", the words matter much less than the dates.
How do you measure both on a plain board?
You need two dates per card, and a third if you want lead time. Write the date a card is added, the date it first moves into an active column, and the date it is finished. A comment on the card or a line at the top of its description is enough. A spreadsheet works too, but the habit of writing down the start date is the hard part.
Three rules keep the numbers honest. Decide once which column counts as the start, and do not change it halfway. Keep the clock running on a blocked card, because the wait is real to the person who asked. Count calendar days unless your team genuinely does not work weekends, and say which you chose.
After about a month you have enough cards to see a range. The cheap way to move it is to limit how many cards are in progress, since fewer open cards means each one gets attention sooner. WIP limits explained goes through why that works, and the link to flow is Little's Law, which says average cycle time equals work in progress divided by throughput (the formal version is here).
Which one should you track first?
Start with cycle time, because it is entirely under your control and it needs only the dates you already have once work begins. Add lead time when people outside the team start asking "when will it be done?", or when you suspect the backlog is where time disappears.
If your board is a personal one, lead time is mostly a measure of how long your own to-do items wait for you, which can be a useful and slightly uncomfortable number. In a pull system the two numbers also tell you whether you are pulling new work at the right pace. You can try this on a board with no signup, adding the three dates to a few cards, and see whether the gap between them surprises you.
Frequently asked questions
What is the difference between lead time and cycle time?
Lead time runs from the moment a card is requested until it is finished. Cycle time runs from the moment work starts until it is finished. Lead time includes the waiting before work begins, so it is always equal to or longer than cycle time for the same card.
Is cycle time part of lead time?
Yes. Lead time is the waiting time before work starts plus the cycle time. If a card waits five days and then takes two days of work, its lead time is seven days and its cycle time is two. Cycle time is the working stretch inside the longer lead time.
Which is longer, lead time or cycle time?
Lead time, or the same length when work starts the moment a card is created. Because it starts earlier and ends at the same point, it cannot be shorter than cycle time for the same card. A large gap between the two means cards spend most of their life in a queue.
How do you calculate lead time and cycle time?
Subtract dates. Lead time is the finish date minus the date the card was added. Cycle time is the finish date minus the date it moved into your first active column. For several cards, calculate each one and then take the average and the median.
Why do some sources say cycle time means something else?
The term comes from manufacturing, where it can mean the interval between finished units. Software writers then used it for time in progress, and some for the whole request-to-delivery span. Always check which start and end events a quoted number uses before comparing it with your own.