In a Kanban model, one thing we find most teams struggle with are WIP limits. Everyone wants to just start one more item even if we’re already at the limit. Surely one more can’t hurt. Except of course, it does.

Nobody violates the WIP limits because they’re trying to be spiteful towards their teammates. They’re doing it because they believe (incorrectly) that starting more work will make the team more effective.

The very counter-intuitive part is that starting that one new piece might actually make that one person more efficient if we measure only their productivity. The problem is that in making them more efficient, we’re almost certainly slowing down the entire team. This can be a difficult concept to grasp and that’s why we struggle with it.

What we care about here is team effectiveness, not individual effectiveness, and what makes this difficult is that we all intuitively assume that making one person more effective must also make the team more effective and yet there is no direct correlation between those two things. Optimizing for an individual often harms the effectiveness of the overall team. Note that we can easily demonstrate that in a simulation but it’s beyond the scope of this article.

Note that while there are many different ways to manage WIP, the most common way is to have a WIP limit on individual columns on a kanban board so we’re going to assume you’re doing the same. Take a typical board like this one:

Typical Kanban board

On this board, we can see that columns A and C are already at their WIP limits. Let’s imagine that nothing in C is able to move right now. These items might be actively in progress or they might be waiting for some reason but the point is that they aren’t moving.

If we’ve finished one of the items in column B, we’ll want to move that item into C but our WIP limits prevent that so what do we do?

The simplest answer is that we leave it where it is in B and we spend our time finishing something in C to make room for it. An important point here is that we don’t do the work associated with column C until we’ve reached that column so if the card is still in B, we’re no longer working on it.

What if we feel we have to move it? Perhaps all the items in C are blocked and there’s nothing we can do to unblock them? One question we can ask is whether the WIP limit is set at the right level. It’s possible that we set it too low and we need to adjust it. As a team together, we can adjust those limits anytime we want so if we feel that they’re at the wrong level then we have the ability to fix that.

If we feel that the limit is set at the correct level and yet we still feel that the card has to move forward then our next option is to expedite it. The very definition of expedited work is that this is more important than other work and it gets some extra permissions. A typical policy for expedited work is that it’s able to exceed the WIP limits by some amount. Note that any classes of service, like expedited, come with their own problems as described here and so this option should be used sparingly.

Always remember that WIP limits are not a “rule” that was imposed on you like a speed limit on a highway. They are an agreement that you made as a team and so as a team, we have to follow them. We made this agreement with the expectation that these limits would make the team more effective and we may have to adjust the limits over time to achieve that outcome.