I’m frequently asked what is the optimal amount of work in progress (WIP) for a team, and everyone is disappointed to hear that there isn’t one.
It depends on the composition of the team, both size and skills, as well as the nature of the work that flows through the team. It depends on dependencies we might reasonably expect.
It also depends on the larger system that the team resides within, although that’s a much larger topic than I want to address right now. That gets into Systems Thinking or Theory of Constraints, and we’ll discuss them another time.
What do we know about work in progress for a single team?
We know that as a general rule, lower WIP across the team will result in work getting done faster and with higher quality, compared to higher WIP across that same team.
We know that there are very rare exceptions to this where WIP that’s too low can actually make things worse. Many teams are afraid that by lowering WIP, they’ll be affected by this, and so they’re reluctant to lower that WIP. Let me assure you that your team almost certainly won’t have that problem. Not for a long time, anyway
We know that it’s possible, despite what many people think, to consistently have a WIP of 1 or 2 across the entire team (see ensemble / mob programming, and those teams tend to be exceptionally effective.
We know that having a WIP that is measured in multiples of the number of people, is almost always a disaster (ie 20 items in progress for a team of 5). The worst I’ve seen was a team of 10 people with 227 items in progress. They spent all day either context switching or arguing over what was important. Nothing got done.
We know that having a WIP that’s too high will invalidate most of the business prioritization that you’re doing.
So what should the WIP be for your team? If you’re asking the question then almost certainly, lower than what it is now. Lower it and see what results you get.
Then lower it again. And again.
See also: the “lowering the water level” metaphor from Toyota.