Explain Lead Time vs. Cycle Time on a Kanban board

This tests your grasp of core Kanban flow metrics. Define Lead Time (customer request to delivery) and Cycle Time (work start to finish). Measure Cycle Time from the first 'In Progress' column to 'Done'. Red flag: defining terms without explaining their value.
WHAT THIS TESTS: This question assesses your grasp of fundamental Kanban flow metrics. The interviewer wants to see if you can move beyond textbook definitions to explain the practical difference between Lead Time and Cycle Time. They are testing your ability to view a process from two different perspectives: the customer's (Lead Time) and the development team's (Cycle Time). A senior answer will connect these metrics to process analysis and improvement.
A GOOD ANSWER COVERS: A strong answer has three parts. First, define Lead Time as the total duration from the moment a work item is created or requested by a customer until it is delivered and provides value. This is the customer's total waiting time. Second, define Cycle Time as the duration from when the team starts actively working on an item until it is completed. This is a subset of Lead Time and reflects the team's internal process efficiency. Third, explain how to measure it. For a single item, you would record the timestamp when the card moves from a backlog or "To Do" column into the first "In Progress" or "Development" column. You then record the timestamp when it moves into the final "Done" or "Deployed" column. The difference between these two timestamps is the Cycle Time.
COMMON WRONG ANSWERS: A major red flag is treating the terms as synonyms. Another is providing definitions without context. For example, just saying "Lead time is from start to finish" is too vague. A weak answer fails to explain why the distinction is crucial. The gap between Lead Time and Cycle Time is often where the most significant process improvement opportunities lie. A large gap (e.g., Lead Time of 30 days, Cycle Time of 5 days) points to excessive time spent in the backlog or waiting for prioritization, not necessarily slow development. Ignoring this insight is a missed opportunity to demonstrate senior-level thinking.
LIKELY FOLLOW-UPS: Expect questions like "How would you use these metrics to improve your team's process?", "What is a Cumulative Flow Diagram and how does it relate to these metrics?", or "If your Cycle Time is low but your Lead Time is high, what problem might that indicate and how would you investigate it?". Be prepared to discuss bottlenecks, Little's Law, and work-in-progress (WIP) limits.
ONE CONCRETE EXAMPLE: Imagine a feature request is created in Jira on May 1st. This is the start of the Lead Time. The ticket sits in the "Backlog" column for three weeks. On May 22nd, a developer pulls it into the "In Progress" column. This is the start of the Cycle Time. They finish the work, it goes through "Code Review" and "QA", and is finally moved to "Done" on May 27th. The Cycle Time is 5 days (May 27 - May 22). The Lead Time is 26 days (May 27 - May 1). The 21-day difference highlights a potential issue with backlog refinement or prioritization, not the speed of development.
Read the original → community.atlassian.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.