What is the purpose of a WIP limit in Kanban?

WHAT THIS TESTS: This question tests your understanding of systems thinking and flow efficiency. The interviewer wants to see if you can move beyond managing people to managing the work itself. They are assessing whether you understand that the goal is not to keep everyone busy (resource efficiency), but to deliver value quickly and predictably (flow efficiency). A great answer connects the abstract rule (WIP limit) to concrete business outcomes like shorter lead times and improved forecasting.

A GOOD ANSWER COVERS: First, state the primary purpose: to optimize the flow of work by forcing the team to finish tasks before starting new ones. This creates a pull system. Second, explain the key benefits: it reduces the cost of context switching, makes system bottlenecks immediately visible, and shortens the average cycle time for work items. Third, provide a specific negative consequence of ignoring limits. For example, if a team ignores its WIP limits, it will accumulate a large number of partially done tasks. This creates a 'traffic jam' where nothing gets completed, lead times become extremely long and unpredictable, and stakeholder trust erodes because delivery dates are constantly missed.

COMMON WRONG ANSWERS: A common mistake is focusing only on people, stating that WIP limits are just to prevent developers from being overworked or stressed. While this is a positive side effect, the primary purpose is to optimize the system's flow. Another red flag is giving a vague consequence like "things will slow down." A senior answer is specific: "Cycle times will increase exponentially, and forecasting becomes impossible because the system is chaotic. You can't tell a stakeholder when to expect their feature if it's one of 20 items that are all 80% complete."

LIKELY FOLLOW-UPS: Be ready for follow-ups like: "How would you determine the initial WIP limit for a new team?" (Answer: Start with a simple formula like 1.5 * number of people in a stage, then adjust based on observation). Another is, "What do you do when a column hits its limit and a high-priority 'expedite' item arrives?" (Answer: Discuss swarming on an existing item to free a slot, or having a pre-agreed policy for breaking the limit, which should be a rare exception).

ONE CONCRETE EXAMPLE: Imagine a team with a WIP limit of 2 for the 'Code Review' column. Two items are currently in review. A developer finishes coding a third item. Because of the WIP limit, they cannot push their work into the review column. Instead of starting a fourth new item (which would increase overall cycle time), they see the bottleneck and help perform one of the two pending code reviews. This clears the bottleneck faster, reducing the total time for all three items to get to 'Done'. Ignoring the limit would have meant three items sat in review, all aging, while a fourth item was started, delaying everything.