WIP limits help us identify bottlenecks in our process, and can provide secondary benefits like facilitating focus and reducing procrastination. But how do we know what WIP limit is appropriate for a particular stage in our process?

Well, the perfect WIP limit would exactly match a stage’s capacity. If we’re talking about a mechanical process such as, say, washing dishes, then our WIP limit should be the number of dishes that fit into the dishwasher.

Rarely are we talking about something so cut-and-dried. We’re usually talking about humans, or worse, groups of humans. And groups of humans are very unpredictable. They tend to go on vacations, and sometimes they have unpredictable schedules. Add to that the complexity that most software delivery or IT processes are themselves irratic. No two user stories or two software deployments are identical.

All this means that it’s very hard, probably impossible, to determine the exact capacity of a stage in software delivery flow. So what can be done?

Well, on one extreme, we could just say that capacity is exactly equal to one per human, and adjust that capacity on a daily (or hourly) basis as people start and stop work for the day. This probably isn’t very practical. It also doesn’t account for the fact that in reality, most people can do a minimal amount of multitasking without serious detriment. If you’re waiting for a 45-minute test suite to run, you can probably start on a second task, and it’s probably not efficient to require every developer to move a user story from “in progress” to “test suite running” every time they kick off the test suite, to stay under a strict WIP limit of 1.

The other extreme is to have no WIP limits at all (or to have them so high as to be meaningless).

Obviously we want something in the middle. And it’s always a tradeoff between the overhead of strict ticket management (which happens if capacity per person is one), and detecting actual, harmful bottlenecks.

The task, then, is to experiment until we find a sweet spot.

I suggest starting with a WIP limit equal to the number of people working a stage times a small number, such as 1.5 or 2. If you have two developers, your “In Development” WIP might be 3 or 4 then.

Then iterate.

Pay regular attention to your WIP limits, and adjust accordingly. Do this at your regular retrospectives, or even more frequently if appropriate.

Pay special attention to two things when evaluating the effectiveness of your WIP limits:

1. Are “in progress” work items becoming stale, or sitting idle for long periods of time?

   This probably means your WIP limit is too high. Your people are taking on more work than they can actually work on, so the work isn’t really in progress. Decrease your WIP limit.

2. Are your people idle, because the WIP limit prevents them from taking on more work?

   This one is a bit harder to solve (and sometimes identify). If this is happening regularly, it’s likely that there’s an as-of-yet unidentified stage that should be added to your kanban board. If developers are waiting hours or longer for some external resource, for example, it’s probably time to add a “waiting for X” column to your kanban board, and move tickets there as appropriate.

   If your developers are legitimately idle due to, say, waiting for a multi-hour test suite to run, then consider increasing the WIP limit.