Purpose and Consequences of Kanban WIP Limits

WHAT THIS TESTS: This question probes your understanding of systems thinking and flow efficiency, core tenets of Kanban. The interviewer is checking if you see WIP limits not as a rule for individuals, but as a mechanism to optimize the entire development system's throughput, predictability, and quality. It separates candidates who think in terms of "keeping everyone busy" (resource efficiency) from those who think in terms of "delivering value faster" (flow efficiency).

A GOOD ANSWER COVERS: A strong answer connects the concept to its systemic impact in four steps. First, state the primary purpose: to optimize the flow of value by creating a pull system. This forces the team to finish existing work before starting new work. Second, explain the mechanism: limiting WIP reduces the average cycle time and makes bottlenecks immediately visible as work queues up before the constrained stage. Third, describe the key benefits: reduced context-switching, faster feedback loops, and more predictable delivery forecasts. Fourth, provide a specific negative consequence of ignoring limits, such as a massive increase in cycle time due to a hidden backlog.

COMMON WRONG ANSWERS: A frequent weak answer focuses narrowly on "preventing multitasking" for individuals, which is a benefit but not the primary systemic purpose. A major red flag is framing WIP limits as a tool for micromanagement or to "stop developers from cherry-picking easy tasks." This demonstrates a misunderstanding of agile principles of trust and empowerment. Another poor response is simply stating "it's a rule in Kanban" without being able to articulate the underlying "why" related to flow and Little's Law.

LIKELY FOLLOW-UPS: Be prepared for "How would you set the initial WIP limits for a team?" (A good start is 1.5x the number of people working in that stage, then inspect and adapt). Also, "What should a team do when a column is blocked and at its WIP limit?" (The team should swarm on clearing the blocker, not start new work in another column).

ONE CONCRETE EXAMPLE: Imagine a team with a "QA" column that has a WIP limit of 2. Developers, ignoring the limit, push 5 items into QA because they've finished coding. The two QA engineers are now overwhelmed. The average time an item waits in the QA queue balloons from 1 day to 4 days. A critical bug is found in the first item, but the developer who wrote it has already started two other tasks and lost all context, making the fix slow and risky. By ignoring the WIP limit, the team created a traffic jam that delayed delivery, increased risk, and reduced overall throughput.