There is no magical formula for how to initially set WIP limits and certainly no one size fits all. It is highly dependent on the team and its unique application. It is more important to simply get started with your new Kanban board than to overanalyze trying to get your WIP limits to their perfect initial settings. Moreover, whatever you initially set them to will likely change over time as the team learns and as changes are made. Having said all that, here are some tips to get started when initially setting WIP limits on a Kanban board.
Just get started with no limits
The simplest and quickest way to begin using your Kanban board is to start with no limits at all. Have the team learn how to pull work from column to column. Observe how work flows through the system for 1-2 weeks. Then set the WIP limits as the best guess that the team believes they should be in order for work to not pile up in any one column. If you go this route, do not wait too long without setting initial WIP limits since this simple mechanism allows the team to easily visualize and address when bottlenecks occur. I would suggest a maximum of 2 weeks.
Set to number of people
Another common approach is to simply set the majority of the columns to the number of people who typically service that column. For example, if you have a column for development and have 6 developers then set that WIP limit to 6. If you have a column for test and 4 testers then set it to 4. A similar option is to divide the number of people by 2 if your team “swarms” or pairs when doing work. So if you have 6 developers then set that column to 3. Yet another variation, in order to encourage a team to swarm, would be to set the WIP limits to number of people minus 1.
Set to number of people X 2
A different approach in order to get started is to set the initial WIP limits to number of people times 2. This allows lots of slack in the workflow – likely too much slack – but it as an initial way to get started without causing too much stress on a team brand new to Kanban. As the team continues to execute then decrease this number. Remember the smaller the WIP, the shorter the cycle time and therefore the sooner value is getting to the customer.
Set to what they have now
One final approach is for the team to start with what they already do now. For example, if a team currently has 10 items in development then start with a WIP of 10.
What about queues?
Most teams have queues or buffers to absorb variations in flow. These queues also allow for an easy way to signal to others that there is work waiting. So, for example, a “ready to test” buffer that the developers place items into to signal to the testers than these items are ready to test. For these buffers, take the best guess as to what the WIP limits should be. Or simply set them to a small number like 2 in order to have a buffer but make it as small as possible.
The done column
Typically the done column has no WIP limits. But the column prior to done, such as “deploy” may have limits assuming the team agrees, for example, that they never want to big bang deploy more than say 10 items.
Continually evolve
If nothing else, this blog should show you that teams have many ways to get started and there is no one size fits all. As the team executes, they will learn what the WIP limits should be in order to achieve a smooth flowing system and will likely continue to adjust these settings. The most important tip is for the team to meet daily as a team and visualize, discuss and not be afraid to continually evolve their board and adjust these WIP limits.