A team member once came to me and said that their team was currently using Kanban, but that they wanted to switch to Scrum. When I asked why their response was: "we need the two-week time-box because in Kanban everything goes into the in-progress column and just stays there." There are clearly many issues that would need to be addressed in this statement (how the team sizes stories, for example), but one that is very important that seems to be ignored on a regular basis is WIP Limits.

What Are WIP Limits?

WIP stands for Work In Progress, which is pretty much any work in a project that has been started but, for whatever reason, has not been completed. With that in mind, a WIP limit would be the maximum amount of work in progress that is allowed at a time in a team or system. A very simplified example of a WIP limit would be, if you have two developers and the team has decided to set a WIP limit of one for each developer, then the total number of development tasks that can be in progress at one time would be two. Although this sounds simple enough, many teams don't seem to place enough emphasis on why they are important which typically leads them to be ignored or used incorrectly. 

Why Are WIP Limits Important?

As much as everyone wants to believe they can multitask well, the truth is that it is always less effective than focusing on one task at a time. In addition, when people work on multiple tasks at once they will typically jump multiple times from task to task which leads to big losses in productivity every time they have to refocus on a task they had previously been working on.

Having a limit on the amount of work that can be handled at any one time prevents people from starting new work when there are tasks that are not finished. Instead of starting a new task when something becomes blocked or too difficult, WIP limits force teams to look at why a particular piece of work has not moved forward (is it too big? Is outside help needed? Are the requirements unclear? Are more developers needed?) and then focus on doing whatever is necessary to finish it so that more work can start to come in and so that the flow of work through the system can resume.

Does Scrum Use WIP Limits?

WIP limits have typically been associated with Kanban, but is it something that Scrum teams can apply? Of course! Isn't the Sprint backlog itself a WIP limit that the team collectively sets for themselves based on their capacity or historical velocity? Scrum teams can take this a step further by introducing Kanban concepts into their Sprints (Scrumban) and setting additional WIP limits for each individual on the team or the types of work they will have to do.

Getting Started With WIP Limits

One of the most important principles for any team working in an Agile fashion (regardless of what Agile frameworks they choose to use) is a focus on continuous improvement. Much of a team's continuous improvement will come from experimenting, inspecting, and then adapting. 

When starting to implement WIP limits for a team this will be no different. At the beginning of any project, especially for a team without much Agile experience, it can be tricky to set an appropriate WIP limit. Make the limit too strict in the beginning and people will get discouraged, frustrated, or even worried. Make the limit too big and then people will be able to work on too many things at once which will, in turn, defeat the whole purpose of having a WIP limit in the first place. 

In order to start, the team should pick initial limits that they feel comfortable with and can commit to following for a period of time. The team can then commit to holding a retrospective session to discuss whether their initial approach has been effective and whether they should revisit the limits that they have set. As the team matures, the WIP limits should get smaller. Ideally, the WIP limit for everyone should be one, but that can sometimes be unrealistic, so the team should always use their best judgement and work on finding a solution that is best for the team as a whole. 

A good place to start may be to set a limit of two tasks per person/role. So if you have two testers on the team, the WIP limit for a testing column on a Kanban board would be four. Regardless of whatever limit the team decides on, the important thing is to always keep revisiting the number and see if there is any way to change it that will help improve a team's process and keep work flowing through the system.

Summary

Although WIP limits are easy enough to understand, too often teams will either ignore them or misuse them. Regardless of what sort of beliefs you have around Agile, Waterfall, Lean, or any other process or framework, the truth is that if teams can learn to focus, they will be able to get more done and deliver value faster, which will then leads to continuous improvement. The power of WIP Limits to help teams maintain this focus makes them a vital tool for any team while on their Agile journey.