WIP Limit in Scrum with Kanban: Who Sets It, What Number, When to Change It

One of the key Kanban practices is Limiting Work in Progress. If you want to be pedantic, what this practice actually aims to do is reduce and stabilize Work in Progress. This improves flow, provides predictability, and is actually even more important for creating a pull-based Kanban system than visualizing your workflow using a Kanban board. I worked with several clients who limited their WIP but didn’t use Kanban boards. One could argue that this practice deserves to be first on the Kanban practices list, ahead of Visualization.

Anyhow, when a Scrum Team implements Kanban, they should definitely figure out how to limit and reduce their Work in Progress. This is a key part of their definition of “Workflow”. Now, a question comes up:

Who should define the WIP Limit?

Let’s assume the team is using Kanban to improve Sprint flow by visualizing and managing the Sprint Backlog. The Sprint Backlog is owned by the Developers, so it would make sense for them to own their workflow, including the WIP limits in this case.

What if the team is using Kanban from a more holistic perspective, starting with the Product Backlog and including refinement work? In this case, the Scrum Team would own the workflow and therefore need to discuss WIP limits. While there are specific accountabilities on the Scrum Team, most importantly, the Scrum Team is accountable for working effectively to deliver value.

Should WIP limits be changed to deal with mid-sprint high-priority work?

Now let’s assume a team is mid-Sprint, and there’s an important, valuable item the Product Owner wants to add to the Sprint Backlog. It is aligned with the Sprint Goal. The team is currently at its WIP Limit. Could they add this item? Should they? What needs to happen to the WIP limit?

My take on this is that, first of all, a decision needs to be made whether to pull this item into the Sprint Backlog. This discussion isn’t related to Kanban at all. It is a core Scrum question, and the answer is that it is up to the team to agree to pull a new item into the Sprint Backlog. The Sprint Goal can be used to assess how aligned this item is with the current focus.

If the item is pulled into the Sprint Backlog, the Developers need to determine whether they can start it right away. This depends on the WIP limits and the current WIP. If the team is at their WIP limit, they shouldn’t pull in that new item until some room frees up. If their backlog items are pretty small, an empty WIP slot will free up pretty quickly. If items are big, it can take a while.

In general, I don’t recommend changing WIP limits on a whim just because there’s a need during the Sprint. I’d rather see an exception and discussion rather than hide the problem under a policy change. Note the exception, maybe even fail to create a really Done Increment, and inspect exceptions later in the Retrospective.

How should Scrum teams limit their WIP?

One last thing to note about limiting WIP is that, while we typically talk about it as per-lane constraints in your workflow, this is just one specific way to do it. You could limit the amount of work in progress per person, for the entire team throughout their workflow, or actually limit WIP by time. For example, “we won’t work on more than 10 items this week”. That sounds familiar: #SprintForecast.

A good starting point is to keep it simple with conservative limits per workflow stage. Observe flow for a couple of Sprints, and then adapt based on aging work, throughput, and bottlenecks.

Some more real-world scenarios

Limiting and reducing WIP is one principle where the real-world application requires nuance. See WIP Limit Anecdotes from Scrum with Kanban Teams for some more examples from the trenches.

Managing and reducing WIP is also a highly fractal principle. Applying it as part of Portfolio Agility can be a great catalyst for starting or Fixing Your Agility.

Figuring out when and how to limit WIP in a way that accelerates sustainable value delivery is a key aspect of my advisory services. Whether it’s at the team, group, or portfolio level, flow is my favorite transformation hack.