Work In Progress Limits are the main attraction of a Kanban-style workflow. By limiting the number of concurrent tasks in a certain state to a hard number, the team gets nudged to improve the overall throughput. When the “To test” column reaches its limits, it’s clear where the focus should be. It would be futile to drag yet another Story to “In progress” since we already have 5 that are 80% Done. Stop starting, start finishing.

All of this is pretty standard fare when it comes to Kanban.

What’s also pretty standard in Kanban teams is a messy Backlog. For all its flaws, Scrum does offer a way to keep the Backlog focused. Each iteration only focuses on a small portion of the Product Backlog. These Sprint Backlogs act as natural focal points. “These are the 17 Stories we will do in the coming weeks”.

Kanban doesn’t have this feature out-of-the-box and the result is often a board with hundreds of tickets in To Do. That’s a recipe for unfocused work. How can a team know what to work on if the board contains an overload of options?

Adding a Story to the board has a hidden cost. Adding a ticket is way cheaper than taking one off. When something urgent comes up (and it always does), we add it to the board to give it the level of attention it needs. The more we add, the more we dilute the focus of the team.

To fight this backlog entropy, Kanban teams need a Work In Progress Limit on the entire board, not just at a column level. It’s vital for focus.

We start by splitting the Backlog into two lists: a Product Backlog and a Focus Backlog.

The Product Backlog can contain a myriad of tickets. It’s the prioritised wishlist of ideas that could be built.

The Focus Backlog is the list of things the team is building right now and should have a hard Work In Progress limit. When we look at the board, we only see the Focus Backlog. A typical development team could start with 2 tickets per dev. For a 5 person team, that’s 10 tickets on the board. The key to focused work is to keep the number of active items to a minimum. By adding a board-level WIP limit, we do just that.

With this in place, focusing comes naturally to the team. When a customer has an urgent request, this ticket can’t just be thrown on the pile. Adding a ticket will break the WIP limit and that requires one ticket to be taken off. The natural tendency to just add to the pile gets replaced with very focused questions:

“Do we drop something we are doing to meet this new request? Do we move a Story back to the Product Backlog? Or can it wait until we finish some of our WIP?”

Teams that work in an environment where there’s a lot of firefighting can take this one step further. They could keep an easy buffer for unplanned work by planning below their board WIPL. If you only have 8 tickets on the board, there’s room for 2 last-minute Stories without impacting the planning.

Adding a ticket to the board has a cost, but by adding a board WIPL it also has a price. One ticket in, one ticket out.