Work In Progress (WIP) is the number of work items that a team is currently working on. WIP limit determines the maximum amount of work allowable in a specific period of time. Limiting WIP is a common best practice in Agile processes as it helps to make blockers and bottlenecks visible. However, limiting WIP is more frequently used in Kanban and not all Scrum teams are paying enough attention to this practice.
Why is Limiting WIP important?
WIP limit encourages a culture of “done” as it requires team to focus on finishing active work items as quickly as possible. This practice is always considered amongst best practices in Agile because of the following main reasons:
- It helps to optimize the work capacity as team can only pull new work into the board if they have available capacity.
- It allows to deliver single work items faster as team will focus on finishing current work items first before starting a new one.
- It is easier to identify blockers as limiting WIP makes blockers and bottlenecks more visible in the board.
Common issues with Scrum teams
If you are working in a Scrum team, you may observe the following common symptoms especially with the “immature” Scrum teams:
- Work items are slowly complete throughout the sprint. We often see “cliffs” in the sprint burndown chart as a lot of tickets are often closed right before the sprint end.
- A lot of work items queuing in Ready for Test column close to the end of the sprint. This causes a lot of pressure to the QC team during this period of the sprint.
- High priority tickets sometimes cannot be delivered in the sprint.
Benefits of applying WIP Limit in Scrum
I have personally applied Limiting WIP in my Scrum teams and observed some significant improvements:
- Work items are gradually closed during the course of the sprint (as reflected in burndown chart below). It’s also easier to assess whether team is having good progress throughout the sprint.
- We have lower risk of not able to deliver high priority tickets in the sprint.
- Workload of QC team is distributed better during the sprint.
- It’s also easier to identify whether team can pick up more tickets into the sprint.
- As pair programming takes place more frequently, we also observe the overall improvement of teamwork
Considerations while applying WIP Limit in Scrum
Even WIP Limit is a common best practice in Agile, there are definitely things to consider if we apply Limiting WIP in Scrum:
- Multiple developers might need to work on the same work item at some points in the sprint. This is not always easy due to the nature of work and not all developers are familiar with pair programming.
- The value of WIP limit needs to be reviewed regularly and team also needs to be flexible with WIP limit. The most important thing is to ensure team always focuses on finishing high priority items as quickly as possible rather than working in a lot of tickets at the same time. We may have some tolerance if strictly following WIP limit could slow down the team in some cases.
- Applying this practice may require task-switching from members in the team during the sprint. For example, when a developer releases a high-priority item to QC team for testing, he may start working in another lower priority item. However, if any bug is found later in the original high-priority item, he will need to come back to fix it as soon as he can.
Key takeaways
Limiting WIP should bring benefits to Scrum teams and help them be more productive, so don’t hesitate to give it a try!
It’s not uncommon that a practice might work well with one team but not (or less) with another team. But as we are doing Agile, “Inspect and Adapt” should be the key to our success!
References
