Lead Time vs Cycle Time in Kanban and measuring Cycle Time

WHAT THIS TESTS: This question checks whether you understand the difference between customer-facing elapsed time and process-internal active time. Interviewers want to see if you use precise Lean and Kanban terminology, know where to place measurement boundaries on a board, and recognize that queues distort delivery predictions. They also care whether you connect these metrics to predictability and service level expectations.

A GOOD ANSWER COVERS: First, define Lead Time as the total elapsed time from when a request enters the backlog until it is delivered to the customer, including all queues and delays before work starts. Second, define Cycle Time as the elapsed time from when work actively begins, typically when an item enters an In Progress column, until it reaches Done. Third, explain that you measure Cycle Time for a single item by recording the timestamp when the card enters the active state and subtracting that from the Done timestamp, producing a duration in hours or days. Fourth, note that Cycle Time is a lagging indicator best tracked with a control chart or cumulative flow diagram to spot variation.

COMMON WRONG ANSWERS: A major red flag is treating Lead Time and Cycle Time as interchangeable synonyms. Another weak pattern is defining Cycle Time as calendar time from backlog to done, which erases the distinction entirely. Some candidates incorrectly exclude blocked time from Cycle Time by claiming it only counts coding hours; in Kanban, blocked time inside active columns still counts because the item is in flight and consuming WIP limits. Saying you would measure Cycle Time by asking a developer to estimate it manually is also a red flag because Kanban relies on empirical start and end timestamps, not guesses.

LIKELY FOLLOW-UPS: The interviewer may ask how you would reduce Cycle Time without reducing Lead Time, which tests whether you understand that shrinking pre-active queues affects Lead Time but not Cycle Time. They might ask what a healthy Cycle Time distribution looks like, expecting you to mention Weibull or log-normal shapes and the importance of controlling variability over averages. Another common follow-up is how WIP limits relate to Cycle Time, where the correct link is Little's Law and the observation that increasing WIP without increasing throughput lengthens average Cycle Time.

ONE CONCRETE EXAMPLE: Imagine a feature request that arrives Monday morning and sits in the backlog until Thursday, when a developer pulls it into In Progress. The developer finishes Friday afternoon and it moves to Done. Lead Time is five days, Monday to Friday. Cycle Time is two days, Thursday to Friday. You capture the Thursday timestamp from the In Progress transition and the Friday timestamp from Done, then calculate the difference. If the item was blocked for half a day waiting for an API key, that half day remains inside the two-day Cycle Time because the card was still actively owned and occupying capacity.