Cycle time vs lead time: the difference, with examples

• Lead time starts when the work is requested, such as when the card is added to the board, and stops when it's delivered.
• Cycle time starts when someone begins the work, usually when the card moves into In Progress, and stops when it's finished.

So lead time contains cycle time, plus however long the card waited before anyone picked it up. Teams don't all draw the lines in the same place, and that's fine. What matters is choosing a start and an end and keeping them the same, so this month's numbers compare with last month's.

A customer reports a bug on Monday 3 November, and it's added to the board the same day. It sits in To Do until Thursday 6 November, when a developer moves it to In Progress. It's fixed and released on Monday 10 November.

• Lead time: 3 November to 10 November, 7 days. That's how long the customer waited.
• Cycle time: 6 November to 10 November, 4 days. That's how long the work took.
• Waiting: 3 of the 7 days were spent in the queue.

If the team wants the customer to wait less, a faster developer saves less time here than a shorter queue would.

• Lead time is the customer's view. Watch it when promises matter: how soon can we usually fix a bug, or deliver a request?
• Cycle time is the team's view. Watch it to see whether the work itself is getting smoother, and where it gets stuck.

Look at the spread as well as the average. "Most cards take 2 to 5 days, a few take 3 weeks" says far more than "the average is 6 days", and the slow ones are where the lessons are.

Little's Law ties 3 numbers together: average cycle time equals average work in progress divided by average throughput, the number of cards finished per day.

If a team finishes 2 cards a day and has 10 in progress, cards take about 5 days on average. Cut work in progress to 6 and, at the same pace, cards take about 3 days. The team didn't work faster; it just started less at once. This is why a WIP limit on In Progress is the first fix most kanban teams make.

• Limit work in progress. Fewer cards started at once means each one finishes sooner.
• Make cards smaller. Large cards wait longer and hide more surprises. Split anything that would take more than a few days.
• Find the waits. Most lost time isn't work; it's cards waiting for review, an answer or an approval. A column like Waiting or In Review shows where.
• Shorten the queue. A long To Do column adds to every card's lead time. Trim what you'll never get to.
• Finish before starting. Help move a stuck card along before pulling a new one.

Every card has 3 dates you need: when it was added, when it started, and when it finished. On a kanban board those are the moments a card is created, enters In Progress, and enters a done column.

craaft doesn't calculate cycle time for you. Each card's activity shows when it moved between columns, with the date of every move, so you can read it off, and the free cycle time calculator does the sums. An agent connected over MCP can read the same activity and work out cycle and lead times across a board for you.

To see where cards wait, give the wait its own column, like Waiting in the task tracker template or In Review in the sprint planning template, and put a WIP limit on In Progress.