How to succeed with WIP limits pt.2
(If you came directly here, please read part 1 first)
Limiting work in progress
Psychology suggests 2–3 work items per person is reasonable (source: Jim Benson), at least for people working on their own. The number per person should go down as team size increases and opportunities for collaboration present itself.
Defining the initial limits
There are various way to apply WIP limits. Since this article is getting long already, let’s keep it simple. I will focus on the most common one, which is WIP limiting individual columns in your Kanban board. Let’s say we have a board with the following columns:
Todo -> Analysis -> In Progress -> Review -> Acceptance -> Done
The four in the middle all represent various states of work in progress. Ideally we’d like to limit all of these, and even the Todo column. The latter to indicate when we are at capacity, and not able to accept more work. You would typically have an infinite queue (in the form of a backlog) outside of the board, but that’s the topic of another post.
I always start with the “In Progress” column based on the (sometimes incorrect) assumption that this is where the work item will spend the most time. My rule of thumb here is as follows:
Even two per person is pretty tough on most teams. Less than one is only possible with mature teams where things like pair programming is the rule rather than the exception.
Where to set the initial limit depends on what the starting point is. The current number of work items will be higher than the new limits. This effectively means the team will not be able to accept more work until they’ve completed enough work to get below the limit. This should be painful, but not too painful. If they currently have ten work items each on average, two per person may be a bit ambitious to begin with. Try to agree as a team, and create ownership and commitment to whatever you decide.
To have a practical example to talk around, let’s say we have a development team with eight developers, and they currently have 36 work items in the “In Progress column. That’s 4.5 work items each on average. In this situation I would probably recommend an initial “In Progress” column limit of 8*2.5 = 20. This means the team will have to finish 16 work items (two each) before they can accept a new one into this main column.
There could be a number of reasons to deviate from this, but my rule of thumb for the remaining four columns is to set it to half that, so 10 each. This gives a total number of work items in progress across all columns of 10+20+10+10 = 50. That’s actually quite a lot for a team of eight people. And when you put it that way, the team may start to understand that as well.
Then what?
Now you have to track the WIP like a hawk in the coming days or weeks, and discuss the trend with the team. Does it stay the same, does it go down (wohoo!) or does it (God forbid) go up? Why?
Prepare to be baffled by the creativity of the team during this period. They will present a myriad of interesting explanations for why they started yet another work item despite having several in progress already. Don’t let them fool you, and remind them of how you agreed to handle blockers.
Eventually the trend should be moving in the right direction. The next step may be reducing it to 8+16+8+8 = 40. And so on.. Keep pushing, and you’ll pick up healthy habits like decomposing and slicing work items as you go.
But what about the Todo column?
I’m glad you asked! When we talked to our customers we asked them to ask for only the most important things. A good way to keep them in check is of course to limit the Todo column as well. Suddenly we’ve got a great way of visualising what they have said is the most important thing. We also have a nice list to show them when they want something new. If the Todo column is at the WIP limit, they have to either wait, or remove something we haven’t started yet.
What should the limit be? Again it depends, but as low as possible. The higher it is, the higher the lead time will be from committed work to delivery. So even though it may be hard to sell, try to keep it low.
Upstream WIP
Even more important than limiting WIP in the team, is to limit it on the company level. A high number of projects or initiatives going on at the same time will challenge the ability to focus for the business side, common services and any other supporting functions. Companies often fail to focus their strategy and efforts. They end up with so many products and services that they are unable to succeed with any of them.
You may not be in a position to impact this directly, but I encourage you to relentlessly challenge those around and above you to focus and prioritize.
Wrapping up
This is difficult stuff. Most “Kanban teams” out there aren’t Kanban teams at all. Either they haven’t even implemented WIP limits, or they’re not enforced.
The goal of all this frustration and hard work is to reduce the lead time and increase focus on what really matters. There are two ways to achieve that. Either to push your WIP limits down, or to reduce the size of the work items. Ideally you should be aiming for both. If you accomplish that, your team will enter the famed flow state. You will build the right things, with higher quality and speed. You will be amazed to find that at the same time stress levels go down. You will be doing more, but it will feel like doing less.
Finally, please note that the numbers presented are guidelines and starting points. If your team is very small or somehow have many natural blockers, higher numbers may be appropriate. If it feels fast, you’re probably fine. If it feels slow, your WIP limit is likely too high.
I hope this have given you some food for thought, and inspired you to limit the work in progress of your team, and ultimately your company. Let me know how it turns out!
Thanks to Mike Burrows and Christina Kjær Seime for input on the first draft.
