How would you apply Little's Law to optimize Kanban WIP limits?

WHAT THIS TESTS: The interviewer wants to see if you can bridge mathematical queueing theory with empirical process control. Little's Law is not trivia; it is a conservation law for stable systems. The question checks whether you understand that Kanban boards are queues, that WIP is not just a heuristic but a controllable variable, and that you can use the identity L equals lambda times W to make a predictive argument rather than a subjective one.

A GOOD ANSWER COVERS: First, define the terms in the Kanban context: L is the average number of items in progress, lambda is the average throughput per unit of time, and W is average cycle time from commitment to delivery. Second, state the stationarity assumption: the law holds for stable systems where arrival and departure rates are balanced over the observation window. Third, rearrange the formula to solve for the variable you care about. If you want to reduce cycle time, you write W equals L over lambda, which means for a fixed throughput, WIP and cycle time are directly proportional. Fourth, propose a specific WIP limit change backed by real or plausible numbers, and explicitly note what you are holding constant and what outcome you predict.

COMMON WRONG ANSWERS: A weak answer treats Little's Law as a vague justification that lower WIP is always better. Another red flag is ignoring the stability assumption and applying the law to a team that is constantly firefighting or has wildly variable demand. Some candidates also confuse cycle time with lead time or forget that lambda is throughput, not arrival rate from the business side unless the system is unconstrained. Finally, suggesting a WIP cut without acknowledging that throughput might drop if the team becomes idle shows a shallow grasp of the trade-off.

LIKELY FOLLOW-UPS: The interviewer may ask what you would do if reducing WIP did not reduce cycle time as predicted, which tests whether you know to question stationarity or hidden queues. They might ask how you handle variability when the system is not perfectly stable, leading to discussion of Little's Law as an approximation and the use of percentile cycle times rather than averages. Another follow-up is how you would apply this at scale across multiple teams with dependencies.

ONE CONCRETE EXAMPLE: Suppose a team has an average WIP of 20 items, a throughput of 4 items per week, and an average cycle time of 5 weeks. The product manager wants an average cycle time of 2.5 weeks. Holding throughput constant at 4 items per week, Little's Law says WIP must drop to 10 items. You argue for lowering the per-column WIP limits so the total in-progress inventory cannot exceed 10. You also propose a policy to pull new work only when an item exits, protecting the throughput assumption by ensuring the team is not idle due to upstream starvation.