What is the primary purpose of a WIP limit in Kanban?

WHAT THIS TESTS: This question tests whether you understand Kanban as a flow management system rather than a task board. Interviewers want to see that you know WIP limits are a core control mechanism, not a decorative metric, and that you can connect policy decisions to delivery outcomes.

A GOOD ANSWER COVERS: First, state the primary purpose clearly: WIP limits exist to constrain how much work is actively in progress at any time so the team finishes items faster instead of starting more. Second, explain the mechanism: by capping concurrent work, the limit reduces context switching, exposes bottlenecks, and enforces a pull system where new work enters only when capacity frees up. Third, describe a specific negative consequence of ignoring limits. Good examples include work piling up in a testing column while developers keep coding, which lengthens cycle time and delays feedback; or quality dropping because fragmented attention leads to incomplete code reviews and rework. Fourth, optionally mention that sustained WIP limit violations eventually erode predictability, making forecasting unreliable for stakeholders.

COMMON WRONG ANSWERS: A major red flag is saying WIP limits are for tracking productivity or holding individuals accountable. Another weak pattern is claiming limits are just guidelines that can be ignored when the team is busy, which misses the point that limits are most valuable precisely when demand exceeds capacity. Some candidates also confuse WIP limits with Sprint capacity in Scrum, treating them as time-boxed commitments rather than per-column flow policies. Finally, avoid framing the limit as a way to keep everyone busy; Kanban optimizes throughput, not utilization.

LIKELY FOLLOW-UPS: An interviewer might ask how you set an initial WIP limit, how you handle a situation where a team member is idle because of a limit, or what metrics you would use to know the limit is wrong. They may also ask how WIP limits interact with classes of service or expedite items.

ONE CONCRETE EXAMPLE: Imagine a team with a WIP limit of three in their code review column. If they ignore the limit and allow seven pull requests to queue, reviewers context-switch between tickets, average review time jumps from four hours to two days, and defects slip through because reviews are shallow. Meanwhile, downstream testing starves for completed work, creating a bottleneck that ripples back and increases overall cycle time by thirty to fifty percent.