How to Set Appropriate WIP Limit for Your Team
The acronym WIP stands for Work In Progress. WIP is the number of tasks a team is currently working on. It frames the capacity of your team’s workflow at any moment. Implementing WIP limits allows an Agile team to complete work units by narrowing focus on ongoing tasks. Work-in-progress (WIP) limits restrict the most significant number of work items in a workflow. WIP limit can be defined per person, work stage/type, or the entire work system. WIP limits are essential for delivering customer value as fast as possible. By applying WIP limits, your team can locate bottlenecks in their working processes before they become a blocker.
Having too high WIP limits means your team, or yourself is always working on many tasks, switching contexts, and failing to meet deadlines. Low limits, on the other side, mean that when a given item is pending on a 3rd party, your members have to wait, i.e., they are idle.
Any task started but not completed is considered a Work In Progress or WIP when working on a project. A WIP limit is set to regulate the amount of WIP in a team or system, the most significant work in progress at any given time. For instance, if two developers are assigned a WIP limit of one, only two development tasks can be in progress. Yet, despite their importance, some teams must pay more attention to WIP limits. It’s important to note that multitasking is less effective than focusing on one task at a time, and teams should emphasize this fact.
WIP limit would be the most significant work in progress allowed in a team or system. Although this sounds simple, many teams need to emphasize why they are essential, which leads them to be ignored or misused. 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. Limiting the work that can be handled anytime prevents people from starting new jobs when studies are still ongoing. Is outside help needed? Do the requirements need to be clarified? 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 the flow of work through the system can resume. Setting an appropriate WIP limit can be tricky at the beginning of any project, especially for a team with little Agile experience. Make the limit too strict, and people will get discouraged, frustrated, or even worried. This will be no different when starting to put WIP limits for a team.
To start, the team should pick initial limits that they feel comfortable with and can commit to following for some time. As the team matures, the WIP limits should get smaller. An excellent 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 the limit, the team should revisit it and consider if any adjustments could enhance their process and keep work flowing.
[¹]: The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
