Cycle Time vs Lead Time: Kanban Metrics for Small Teams

Cycle time is the time from when work on an item starts to when it finishes. Lead time is usually longer: it starts when the item was asked for, so it includes the time the item spent waiting before anyone picked it up. Usage varies between sources, so the best practice is to write down your own start and finish points and stick to them. For a small team, four numbers are enough: work in progress, throughput, work item age and cycle time. All four can be worked out by hand from a board’s history, and a percentile, such as “85% of our tasks finish within 9 days”, tells you far more than an average.

Definitions, and why usage varies

There is no single authority for these terms. The Agile Alliance glossary entry for lead time↗ (opens in a new tab) defines lead time as the time between identifying a requirement and fulfilling it, and cycle time as the time between starting work on a story and making it available for delivery. It notes that some authors see lead time as the user’s view and cycle time as the developer’s.

Kanban University’s guide↗ (opens in a new tab) uses lead time differently: from the commitment point, when the team agrees to do the item, to completion. That is closer to what others call cycle time. So when two people compare lead times, check first that they started the clock in the same place.

• Lead time: from created (or requested) to finished. What the person who asked experiences.
• Cycle time: from started to finished. What the team controls most directly.
• The gap between them is queue time: how long work waits before anyone starts it.

The four flow metrics in the Kanban Guide

The 2025 edition of the Kanban Guide↗ (opens in a new tab) renamed its “Kanban Measures” to Flow Metrics and names four as mandatory. It does not mention lead time at all, and it says teams may call the metrics by other names, for example flow time for cycle time, as long as they use them as described:

• WIP: the number of work items started but not finished.
• Throughput: the number of work items finished per unit of time, counted exactly.
• Work item age: the elapsed time between when a work item started and the current date.
• Cycle time: the elapsed time between when a work item started and when it finished.

In every case, started and finished mean whatever the team has defined them to be. On a four-lane board the natural choice is started when a card enters In Progress, and finished when it reaches the last lane as done.

Measuring with nothing but task history

You do not need a metrics tool. You need, for each finished item, three moments: when it was created, when it first moved into your started lane, and when it moved into your finished lane. Any board that records moves with a time gives you those. Once a week:

1. List the items finished that week, and for each one note the three dates.
2. Cycle time is finished minus started. Lead time is finished minus created. Count in calendar days, and decide once whether an item started and finished on the same day counts as 0 or 1.
3. Throughput is how many items finished that week. Decide whether items closed as not needed, such as duplicates, count. Most teams leave them out.
4. Work in progress is how many items are in your started lanes right now.
5. Work item age is today minus the started date, for each item still in progress.

Two rules keep the numbers honest. If an item goes back from In Progress to an earlier lane and later starts again, use the first start, or it will look faster than it was. And change the definitions only deliberately, noting the date, because a change of definition looks exactly like an improvement.

A worked example

Here are ten tasks a small team finished in September, with the date each was created, moved into In Progress and moved to done:

task     created  started  finished  cycle  lead
BUG-101    1        2        3         1      2
FET-102    1        4        5         1      4
ENH-103    2        3        5         2      3
BUG-104    3        8       10         2      7
FET-105    1        7       10         3      9
ENH-106    4        9       12         3      8
FET-107    2       10       14         4     12
BUG-108    8        9       14         5      6
FET-109    3       11       20         9     17
FET-110    1        5       25        20     24

• Cycle times, sorted: 1, 1, 2, 2, 3, 3, 4, 5, 9, 20. Average 5 days. Median 3 days.
• Lead times, sorted: 2, 3, 4, 6, 7, 8, 9, 12, 17, 24. Average 9.2 days. Median 7.5 days.
• Throughput by week: 3 tasks (1 to 7 September), 5 (8 to 14), 1 (15 to 21), 1 (22 to 28).
• Queue time: the average gap between lead and cycle time is over four days, so work waits about as long before it starts as it takes to do.

Percentiles, not averages

The average cycle time above is 5 days, yet eight of the ten tasks took 5 days or less. One 20-day task pulled the average up. Work items do not take normally distributed amounts of time: most are quick and a few are very slow, so the average describes almost no real task.

A percentile says what share of items finished within a given time. To find the 85th percentile of ten items by the simplest method, sort them and take the item at position 85% of 10, rounded up: the 9th, which is 9 days. So “85% of our tasks finish within 9 days”. Spreadsheet percentile functions interpolate and may give a slightly different figure; pick one method and keep it. With only a handful of items, treat any percentile as rough.

This is exactly the form the Kanban Guide uses for its service level expectation, a forecast with two parts, a period and a probability, such as “85% of work items will be finished in eight days or less”, based on historical cycle time. It is also a sentence you can say to the person asking when their request will be done.

Work item age: the metric you can act on today

Cycle time only exists once an item is finished, which is too late to help it. Work item age is the live version. Say that on 28 September the team has two tasks in progress: FET-111, started on the 15th, is 13 days old, and BUG-112, started on the 24th, is 4 days old. Against the 85th percentile of 9 days, FET-111 is already older than 85% of recent tasks took in total. That is the item to talk about at the next stand-up: is it blocked, too big, or quietly abandoned?

Ageing work is also where a WIP limit shows its value. The fewer items in progress, the fewer can age unnoticed.

Kanban metrics best practices for a small team

• Write down where the clock starts and stops, and put it where the team can see it.
• Track the four flow metrics before anything else. Add others only when a question needs them.
• Report cycle time as a percentile with a period, never an average alone.
• Look at work item age every day and cycle time every week or two.
• Use the numbers to ask why, not to rank people. A long cycle time is usually waiting, not slow work.
• Keep the arithmetic simple enough that anyone on the team can redo it.

The GOV.UK Service Manual’s introduction to agile methods↗ (opens in a new tab) says Kanban helps a team predict its output based on actual delivery. That is what these numbers are for: forecasts built from what really happened, not from estimates.

On fenbs: the history is there, the sums are yours

fenbs does not calculate cycle time, lead time, throughput or work item age. What it does is record every change with who made it and when. The History page lists the board’s trail, and each task’s own page has an Activity section with just that task’s lines. A move reads as the person or AI assistant, the task, and the lanes it went between, such as To Do → In Progress, with how long ago it happened: in minutes, hours or days, and in months once it is more than 30 days old. A task’s creation is a line too, which gives you the start of lead time.

• WIP: the count beside the In Progress lane, also shown as a tile in the Insights panel above the board.
• Cycle time: on a finished task’s page, the gap between its move into In Progress and its move into Completed.
• Lead time: the gap between its created line and its move into Completed.
• Throughput: tasks moved into Completed in the period. A task in Completed also records how it ended, Completed, Won’t fix, Duplicate, Cannot reproduce or Obsolete, and Insights already counts only the ones that were built.
• Work item age: how long ago each task in In Progress was moved there. The History can be searched by a task’s ref and sorted oldest first.

The History page shows the most recent 200 changes on the board, so for a busy board read each task’s own Activity instead. Copying the dates into a small spreadsheet once a week is enough to do everything in the worked example above.