Our team is struggling with overload and a slow delivery pipeline—classic signs of high WIP (Work In Progress). We want to adopt Kanban principles but are unsure how to correctly set and enforce the initial WIP limits for our columns like "In Dev," "Testing," and "Code Review." Should the limit be based on the number of people in the stage, or should it be based on the workflow efficiency and average Cycle Time of the entire process? How do you effectively manage team members who instinctively want to pull more tasks than the limit allows?
3 answers
The simplest and often most effective way to set initial WIP limits is to start with the number of people in that stage (e.g., 3 developers, limit of 3-4 for "In Dev") and then immediately reduce it by one. This forces the team to identify and address bottlenecks right away. Ideally, the limit should be based on the capacity of the bottleneck stage to maximize workflow efficiency. The goal isn't busy workers; it's completed work, which requires a continuous flow. To enforce it, the Kanban board needs to be the single source of truth—if a column is at its WIP limit, team members must swarm or collaborate on existing work to move it forward rather than pulling new tasks. This is the pull system in action. Make the rule an explicit policy that the whole team commits to.
That makes sense as an initial step. But if the goal of Kanban is true continuous flow and improved delivery pipeline, what kind of team-level retrospective or feedback loop is best used to adjust the WIP limits over time? For example, if we successfully reduce our Cycle Time by 20% after one month, should we then lower the WIP limit again to push for further workflow efficiency, or does reducing the limit too aggressively introduce too much variability and risk to the team's capacity and overall WIP?
Start by setting the WIP limits to the number of people in that step minus one. Enforce the limit by making it a team policy that when a column is full, the team must collaborate to clear the bottleneck for better continuous flow.
Emphasizing the pull system is key. If a developer is done, they pull work into their column only if the limit is not met, otherwise, they push existing work forward. This action is what reduces high WIP and improves the delivery pipeline.
David, the Kanban practice of the Flow Review is designed for exactly this. It's a review focused solely on the flow metrics—Cycle Time, throughput, and WIP. If Cycle Time drops significantly, it's a great sign that the current WIP limit is working, and the team is pulling efficiently. A common next step is to experiment by lowering the limit by a small amount to see if further improvement is possible without damaging quality. The key is small, iterative changes based on metric data, not gut feeling.