Teams new to Kanban often spend far too much time debating what their initial work-in-progress (WIP) limits should be. It’s not that they don’t understand Little’s Law or disagree that WIP limits serve as a useful constraint. It’s just that they don’t know how to set them.
Here are the three most important things to know:
- There’s no perfect answer
- Don’t skip setting WIP limits
- Start with something, observe, and adjust as needed
But if you were hoping for a little more to go on, here’s some additional information.
Setting overly aggressive WIP limits right away, especially if it’s a big change for the team and organization, can create resistance and stress. It’s generally a good idea to start a little looser initially, then gradually tighten WIP limits over time, while observing the impact of any changes.
To increase buy-in and the likelihood that people will follow the limits, try setting them as a team and involving any upstream partners that send work to the team.
Common WIP Limit Approaches
Single item flow
Little’s Law tells us that the less WIP, the shorter the cycle time. So, single item flow (WIP=1) may be the ideal for speedy delivery. However, often this isn’t practical and could end up being too restrictive.
2 items per person (or pair if pair-programming)
This is a common limit, aiming to keep WIP low, while still allowing some flexibility for when items get blocked.
Setting a WIP limit one under the number of team members is a common way to encourage swarming and greater collaboration by forcing team members to work together.
Start with what you do now
Often the best, and simplest, approach is to simply start with, or close to, what you already do now. So, if you team currently has 12 items in development at once, start with WIP=12. Or if the team feels ready, maybe go with WIP=10. Either way, the goal should be to observe the impact on the system and then adjust as needed.
In summary, there’s no magic formula. Use the information available now, take your best guess, and understand that you’ll continue to empirically adjust the WIP limits.