As a Project Lead or Agile Scrum Master you probably know the feeling: the whole team is frantically hammering out user stories, and they’re all “almost ready”. It seems to be taking an eternity until even a few of them start flowing into the “done” category. In most cases, the cause is your team is taking on too many tasks at the same time. Delay is the inevitable consequence. That's a structural problem you need to tackle in a serious way. How? By using WIP limits.
WIP (Work In Progress) limits are a term taken from Kanban. They enable a team to maintain an optimal delivery tempo without exceeding their capacities. It's the figurative “brake” on the Kanban board, which requires the team to first complete the “in progress” tasks before any new tasks can be introduced.
Multitasking. It’s a fancy-sounding word that a lot of people like, but it’s certainly not efficient. Multiple studies have shown that there are three fundamental factors in inefficiency, and the biggest of them all is switching between multiple tasks. Why?
WIP limits ensure that teams stay focused on finishing tasks. They help prevent bottlenecks of work piling up.
It’s everybody’s dream: just being able to work on your individual tasks, with no interruptions. In practice, of course, that’s easier said than done. Generally, we are struggling with dependencies between different tasks. That’s why it’s important to minimize these dependencies or to blend them in a way that allows them to be handled in the right sequence.
That's why the exact WIP limit will depend on the number of people on the team and the volume of individual tasks. A good rule of thumb is to start with the number of team members plus 1. For very large projects, you can use the formula: number of team members plus 2.
That means on a team of 4 members, you can set a WIP limit of between 5 and (maximum) 8 tasks.
Optimizing productivity and efficiency is something that is never finished. Fine-tuning the team’s functioning and striving for a stable and effective cycle time can always be worked on and improved. Both also vary according to the situation of a project.
Thinking of trying to work with WIP limits? Keep in mind that a team generally needs an average of two weeks’ adjustment period to get used to a new way of working.
After you introduced it, you can start looking at the effect the WIP limit is having on your project’s cycle time. Is the work still piling up or is the team getting snowed under? That means your WIP limit is too high. Did your team members, on the other hand, find that they had too much passive time? Then you can definitely increase the limit.
The WIP limit is a handy tool for creating more efficiency in any software delivery cycle. But it’s important to keep it attuned to the project and the team.