The Magic of WIP Limits in Kanban

Written by David Raffauf

Using WIP limits leads to better communication within a team. It emphasizes completing work over starting work. It forces more conversations and collaboration to happen that help move work through the process efficiently.

What are WIP limits?

One tool we’ve used at UserTesting with great success is Work In Progress (WIP) limits. In a Kanban workflow, these are limits on the amount of work that can be in progress at a given time. These limits can even be applied to each state of a workflow. Changing these limits can quickly change dynamics and incentives.

What are the benefits of using WIP limits?

Using WIP limits leads to better communication within a team. It emphasizes completing work over starting work. It forces more conversations and collaboration to happen that help move work through the process efficiently. It encourages spreading knowledge among the whole team. It also helps to clearly communicate to other teams and the whole organization what work is really in progress at the moment, and what’s coming next.

How do WIP limits work?

Lowering WIP limits reduces the amount of work that can be in progress. Let’s say we have a WIP limit of five and there are already five cards in progress—we’ve hit the WIP limit.

Because the WIP limit has been reached, new work can not be started. Since the overall goal of an agile team is to ship value whenever possible, our example engineer is going to start looking for how to help at the end of the process and work backwards.

What’s an engineer to do?

Step 1: Ship value to customers

The first place to check is to see if there’s code that is completed, verified, and ready to release. If so, the engineer could theoretically ship the code. In practice, it’s probably better for our engineer to follow up with whomever did the work and encourage them to ship it. If there’s nothing ready to release, the engineer can move back a step in the process.

Step 2: Verify completed work

If there is work that has been completed, code reviewed, but not verified, the engineer has a couple of options. They could attempt to verify it themselves by verifying that each of the acceptance criteria is met. It’s sometimes helpful to take screenshots or a screencast to demonstrate to others that the acceptance criteria have been met.

In practice, it might be better to reach out to either a QA engineer or the product owner so they are able to confirm that it works as expected. This is important because while acceptance criteria try to capture what needs to be done, there can still be miscommunication over the details.

Step 3: Review code

If there isn’t any work that needs verified, the next option for our engineer is to review code that’s ready for code review. Simply by having lower WIP limits we’ve forced reviewing code to be a required part of the process. Now it’s an active step to take when new work can’t be started. No longer will the engineer grab the next story, hoping someone else gets around to reviewing code.

Step 4: Pair with another engineer

If there isn’t any code that needs reviewed, the engineer can pair with another engineer to complete existing work in-progress. Lower WIP limits encourages this kind of collaboration. This is good because of all the known benefits of pairing, but specifically helps with making better design decisions which in turn make our code more maintainable.

It also helps spread knowledge across a team, both in terms of technique and domain knowledge. Without pairing it’s very easy for a team member to become the one-and-only expert for a certain domain. If that person switches teams, leaves the organization, or is out on vacation, it’s possible that no one can lead work in that area.

Step 5: Clarify features and bug reports

If all else fails and the engineer can not contribute to work in progress there are still several options available. They can look at other cards in the Backlog to see if they need clarification and have necessary discussions with the product owner. They can look at bug reports to see if they include the steps to be reproduced and any relevant information from logs. This may lead to discussions with QA engineers or bug reporters.

Step 6: Enjoy slack time

If there’s truly nothing to be done in terms of cards on the board, this is a perfect reason to take advantage of slack time. This can come in the form of working on lower priority projects, improving the development environment, contributing back to open source, or writing a blog post to share with the development community.

What happens without WIP limits?

Without WIP limits, it’s always a valid option to start on the next card in the queue. This process optimizes for work started, not work completed. With lower WIP limits the incentive is always to see how work that has been started can be completed.

Without WIP limits, a large card can remain in progress for weeks because it isn’t blocking bringing in new work. Low WIP limits strongly encourage breaking down work into small pieces. If there’s a large card in progress that is blocking other engineers from starting work, it will immediately lead to discussions about how to break down current and future cards into smaller ones. Typically if something sits in one part of the process for a day or two, that’s enough to force the conversation.

How does this affect daily stand-ups?

This brings clarity to daily stand-up meetings. If each card’s state and the steps needed to move forward are discussed it leads to much more interesting conversations than simply asking if any team member is blocked. The answer to that will almost always be, “no”, even if cards don’t have a clear path forward.

Discussing each card’s path to Done is a good opportunity to see if a team member is really blocked or has more work in progress than they can possibly be doing at one time. This is a good opportunity to hand off work to other engineers or simply pull cards into the backlog until they’re actively in development. It’s also a good opportunity to ask if the card is just too big or there are too many unknowns to move it through the process which is a slightly different question than a simple, “are you blocked?”

How does this affect product owners?

For product owners this reduces the number of simultaneous conversations happening about cards in progress, and it encourages engineers to have conversations with product owners when they’re prepared to move a story quickly through the process. Without WIP limits, a product owner could be discussing dozens of cards that may take weeks to complete instead of the five or six that will be done in the next couple days.

What is a good WIP limit?

These are just some of the benefits that can come from lowering WIP limits. I have had the most success setting work in progress limits to roughly half of the of number of engineers. This creates the situation where about half of the time an engineer is going to look at alternatives to starting new work.

Why not give it a try?

While it may be a little counterintuitive, working within tighter limits can really improve your process. I highly recommend trying them for an iteration. If you’re already using them, try experimenting with lowering them to see how it changes your workflow.

WIP limits are just one example on this theme of constraints. Subscribe to our email list to get updated on new posts. I’m sure we’ll continue to explore new articles on this topic.