How to specify WIP limits in Kanban?

Question

Consider a typical Kanban board:

Input, Analysis, Dev Ready, Development, Build Ready, Test, Release Ready

How to specify WIP limits for each column? any formula?

Answer 1

No, no formula. There isn't one.

Much depends on the way your team works, practices you use, etc. If you pair program you will have lower limits in development column than a number of developers.

If you introduce Kanban in existing team you can try to map all the work which is currently in progress into MMFs, and then see how many features you do have in different columns. It would give you some insight what limits you really have at the moment and this is a good starting point to set Kanban limits.

Another advice you get is go with your/your team's gut feeling. Do what you feel is right. Then monitor whether your limits aren't too tight or too loose and adjust. Some people say "the board will tell you" and that's basically true. If you hit the bottleneck every single week you probably have you limits set too low. If one or two blockers aren't a problem limits are too high.

I wrote a post how we set our limits when we were crafting our Kanban board: http://blog.brodzinski.com/2009/11/kanban-story-kanban-board.html

Answer 2

I've tried two extremes, both suggested by different people. One is to use high limits and tweak them down until it hurts, and the other is the opposite, to start with n-1 where n is the number of people who could pull a task to that column. The latter is more painful for teams new to kanban, but it helped us to arrive at a flow maximizing point faster than the first option because when we felt pain (bottlenecks) our first instinct was to examine the problem with raising the WIP limit as a last resort and as a result, we uncovered and solved several process issues that might have been invisible otherwise.

Answer 3

While I agree there is no formula as such - at the same time there is the real possibility of modelling your Kanban process. This will help you simulate likely outcomes for things such as Cycle Time, Wait Time, Efficiency, etc.

I have implemented such a simulator which models our Kanban process. It simulates the flow of stories across the board under our Kanban constraints around WIP limits and team resources. We have a state requiring external customer review. We all suspected that this stage was something killing our Cycle Time by backing up our stories.

The gut feel was to time box this stage but we didn't know if this would simply push the problem elsewhere. Nor did we know how far to go with the time boxing nor how big an improvement it would make.

It's all very well saying just carry on tweaking but it can be very disruptive. People will get used to a process and get frustrated with someone constantly trying to tweak on a hunch. So you often have to make a very good case before implementing change.

When you model you can tweak without disruption and have a far greater confidence that your tweaks are going to deliver the outcome you want. Plus it will go someway to getting you your magic formula.

Answer 4

I'd start with a number of "slots" in each column that is equal to the number of people that would pick up work in the associated column. That will reveal bottlenecks or pain points. Address the pain point until it is gone.

Over time experiment with reducing the number of slots in each column.

Answer 5

I use two techniques for specifying WIP limit when we start a new project or a team.

In case of a development project: we are working in pairs (we are doing XP), which means that two members can work on one element at a time. If the team consisted of 6 people, the WIP would be 3, based on the previous sentence. However pair programming is an exhausting job, and sometimes colleagues would like to work a bit alone, I give a plus one, so the WIP limit for 6 members would be 4.

When we are talking about a maintenance, verification test or support project, then I check how much parallel work the different colleagues can do, I sum this number and I subtract it with one. For example everybody from the previously mentioned team can take care of 2 parallel issues, it would make the WIP limit 12, but with the -1, it is 11. The -1 ensures me that the team stays focused, and works together. If in this case the WIP limit were 12, everybody would work on his/her maximum two cards, and no collaboration would happen.

I want to empathize that I use these techniques only at the beginning when the project/team starts. Afterwards the adjustment of the WIP limit is the duty of the team based on their feelings, load, goal etc.