A team member once came to me and said that they’re 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, 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 they 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 worked on at 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? Do we need more developers?) 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.
WIP Limits in Scrum?
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 teams 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, especially in the earlier stages of a project as teams are still learning how to work together to effectively remove any items that may get blocked at some point in their process.
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
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 lead to continuous improvement. The power of WIP Limits to help teams maintain this focus makes them a vital tool for any team looking to progress along their Agile journey.