Apply Little's Law to a Kanban system to optimize flow

WHAT THIS TESTS: Your ability to go beyond agile buzzwords and apply fundamental mathematical principles from queuing theory to manage software development flow. It's a test of data-driven decision-making and your understanding of the core mechanics behind why Kanban's WIP limits are effective. The interviewer wants to see if you can use a simple formula to create a compelling argument for a process change.

A GOOD ANSWER COVERS: Three key points in order. First, clearly define Little's Law and map its variables to Kanban terminology: L (average items in system) becomes Work in Progress (WIP). λ (arrival rate) becomes Throughput (items completed per unit of time). W (average time in system) becomes Cycle Time. The formula is WIP = Throughput * Cycle Time. Second, rearrange the formula to solve for the desired outcome. For example, to reduce Cycle Time, the formula is Cycle Time = WIP / Throughput. This shows that if Throughput is stable, the only way to decrease Cycle Time is to decrease WIP. Third, provide a concrete example with numbers to argue for a specific change in WIP limits.

COMMON WRONG ANSWERS: A major red flag is simply reciting the formula without explaining its practical application. Another is confusing the terms, like mixing up Cycle Time and Lead Time, or Throughput and Velocity. A more subtle error is presenting the law as a magic bullet without acknowledging its assumptions, namely that it applies to a stable system over a long-term average. An answer that suggests you can arbitrarily change one variable without affecting others (e.g., "let's just double throughput") shows a naive understanding. The relationship is more complex; for instance, excessively low WIP can starve the system and actually decrease throughput.

LIKELY FOLLOW-UPS: "What are the prerequisites for Little's Law to be applicable to your system?" (Answer: The system must be stable, meaning the average arrival rate is equal to the average departure rate, and it's not in a transient state). "What happens if you lower WIP too much?" (Answer: Throughput can drop due to starvation, where downstream stages are idle waiting for work). "How would you measure these three variables on your team's Kanban board?" (Answer: WIP is a direct count. Cycle Time is the average time from 'In Progress' to 'Done'. Throughput is the count of 'Done' items per week).

ONE CONCRETE EXAMPLE: "Our team's average WIP is 20 tasks. Our throughput is 10 tasks per week. Using Little's Law (Cycle Time = WIP / Throughput), our average cycle time is 20 / 10 = 2 weeks. The business wants to reduce the time-to-market for features. I would propose an experiment: let's reduce our WIP limit from 20 to 15. If we can maintain our throughput of 10 tasks/week, our new theoretical cycle time would be 15 / 10 = 1.5 weeks, a 25% reduction. We would monitor throughput closely to ensure it doesn't drop due to the lower WIP."