The benefits of WIP limits in Kanban

Agile development timelines

To understand time spent on software development projects, start with the simplest project scenario. A one-person team is equipped with everything they need to develop software. That person is working on three projects. Each project takes 30 days in the code and test workflow to complete. If the programmer completes the projects one at a time, they end on day 30, 60 and 90, for an average of 60 days. If the programmer multitasks, with no context-switching costs, they finish the three projects on day 88, day 89 and 90, for an average length of 89 days per project.

The average completion time for these software projects is 60 days versus 89 days, or more than 30% speedier time to market with a sequential approach. In reality, most projects have dependencies and more team members, and context switching between a number of tasks on disparate projects takes a toll on productivity. With these factors, the effectiveness of a software team falls to a single-digit percentage of what it could be in ideal conditions. Projects that should take a day to get from concept to production can instead take weeks or months.

Projects that should take a day to get from concept to production instead can take weeks or months.

WIP grows because of the perceived waste of time spent waiting. Take, for example, a software team that typically works on five to eight projects at a time. Each project gets stuck on a blocker somewhere: A requirements question needs an answer; the programmer needs permission granted to use a database; and other causes. If all the people lined up in the same room to work on the project and handed work off, the project might take a total of two weeks. Instead, it could take two or three months, much of which is spent not on work, but on waiting.

Waiting is one of the common wastes of Lean development. The correct practice is to make the wait visible, discover the blocker or bottleneck, and fix it. Instead, companies fill in the wait with more work. Increasing WIP does improve bandwidth but harms responsiveness, muddles priorities and drains the team's mental energy as they switch between assignments.

Kanban WIP limits create a pull system

Agile software development work is represented by cards on a Kanban board. Programmers work the board in order, from left to right. The board has a number of slots in each column, and it is not possible to add more cards to the bottom. Teams generally work in Agile project management software, but the approach is modeled on these physical Kanban boards and retains the same functionality.

Most modern software teams use an Agile project management tool, such as Atlassian Jira, Microsoft Teams, Pivotal Tracker or Planview AgilePlace to track development projects. Online tools typically offer standard, Scrum and Kanban views of the work. Most Kanban templates have a WIP limit variable.

When team members want to pull more work from the backlog on the far left of the board into the workflow, they need open slots. When the slots are full, the technical staff cannot add more work. Instead, they go help someone else with their WIP.

Here's an example of an Agile development workflow that limits WIP. On the Kanban board shown in Figure 1, the Code review column has one slot. If a programmer pair finishes work and wants code review but someone else was ahead of them and filled the code review slot, they cannot add their card to the Code review column. This programming pair must stop and offer the code review, not pick up new development work. This approach is a pull system, where the next stage asks for work when it is free. Most software development projects are push systems, where the focus is on completing work and moving it to the next stage.

To implement a pull system of Agile development, set WIP limits. In Figure 1, the set number of open spaces are intentional WIP limits. Some columns have more WIP capacity than others. The team simply cannot place cards in slots if they're already full.

Setting WIP limits

The simplest standard for a WIP limit is one per workstation. For example, a team with six developers working in pairs and three QA team members might have three In development columns and four for In testing. This team would add columns for Code review, Story kickoff or Test case creation, and Waiting for deploy. By limiting WIP in those columns, the team creates more pull.

Some teams create a single extra slot for emergencies, which includes emergency fixes. This mostly aids management. When something absolutely must be done, the team can flex to WIP limit, plus one. An extra slot makes even emergency work visible, trackable and possible to plan for. If the team discovers it has an excessive amount of emergency work, that should prompt reflection and corrective action.

Reviews of overall throughput and delays, held every two weeks, could lead to small experiments to reduce or enhance WIP.

How to handle excess work

Richard Sheridan, CEO of Menlo Innovations in Ann Arbor, Mich., once described his work as a vice president of software for a company. Every quarter, after presenting progress to the senior leaders, he would be accosted by executives who wanted to get their unofficial, off-the-books pet project going. This kind of off-the-books work happens in software; one team I worked with called these people velociraptors, as the work steals velocity.

Having an emergency WIP exception is one way to deal with this scenario. Teams cognizant of their performance metrics can understand, predict and model the effects of escalating a microfeature or fix. The problem is when a great deal of these fixes arise or when they aren't officially on the books. The solution to that is better organizational culture.

If the off-the-books tasks total more than a specific amount of time per week, determined by the team, they must be recorded as a task and go through the formal project system. This change can be uncomfortable at first, but it does force a distinction between pet projects and real priorities.

A team that tracks how long it takes a marketable feature to be released, before and after WIP limits, has a responsiveness metric that matters. They also have proof of the cost of side projects and multitasking when those pop up.