How would you apply Little's Law to a Kanban system?

WHAT THIS TESTS: This question tests your ability to move beyond agile buzzwords and apply quantitative, data-driven principles to process management. The interviewer wants to see if you understand the fundamental relationship between work in progress (WIP), cycle time, and throughput. It's a test of your systems thinking and your ability to use data to make a compelling argument for change, a key skill for senior engineers who are expected to improve not just code, but also the process that creates it.

A GOOD ANSWER COVERS: A strong answer has four parts. First, clearly state Little's Law in the context of software development: Average Cycle Time = Average Work In Progress / Average Throughput. Second, explain the direct implication: if throughput is relatively stable, the only reliable way to decrease the average time it takes to complete a task is to decrease the number of tasks being worked on simultaneously. Third, provide a concrete, numerical example of how you would use this to advocate for a change. Fourth, briefly acknowledge the law's main assumption: it applies to long-term averages in a relatively stable system.

COMMON WRONG ANSWERS: The most common red flag is reciting the formula L = λW without translating it into Kanban terms (WIP, Cycle Time, Throughput). Another mistake is failing to provide a specific, numerical example. This makes the answer abstract and suggests you haven't actually used the concept. A less obvious error is presenting WIP reduction as a free lunch. Senior candidates should acknowledge potential trade-offs, such as the risk of developer idle time or process bottlenecks if WIP is lowered too aggressively without addressing underlying constraints. Confusing cycle time (time spent actively working on an item) with lead time (time from request to delivery) is also a frequent error.

LIKELY FOLLOW-UPS: Expect questions that test your influence and deeper understanding. For example: "How would you persuade a team that feels lowering WIP will make them less productive?" or "What other metrics would you monitor to ensure this change doesn't have negative side effects, like on quality or team morale?" Another common one is, "What do you do when your system isn't 'stable' and your arrival and departure rates are highly variable?"

ONE CONCRETE EXAMPLE: "Imagine our team's dashboard shows an average WIP of 15 tickets. Our historical data shows we complete, on average, 3 tickets per week. This is our throughput. Using Little's Law, our average cycle time is 15 divided by 3, which equals 5 weeks. A stakeholder is complaining that features take too long. I would propose an experiment: let's enforce a hard WIP limit of 9. Assuming our throughput stays at 3 tickets per week, our new theoretical cycle time would be 9 divided by 3, which is 3 weeks. This is a 40% reduction in cycle time. We can sell this as a way to deliver value faster without asking the team to 'work harder,' but simply to 'work smarter' by focusing on fewer items at once."