A common issue with most teams is to focus on everything at a time.
Think of a scrum team of 6 engineers working in a 2-week sprint cadence. They have a subset of backlog, the Sprint Backlog, to focus. The sprint backlog is something they have committed to accomplishing in a span of 2 weeks.
Now, think of a sprint that has around 7 stories and 2 spikes committed. 6 people and 9 items to work.
What I have seen in my experience that the teams in the above scenarios tend to start either on 3 to 5 items immediately at the start of the Sprint, OR they start on 2 to 3 items and as they progress in the sprint they have five to six in progress at the mid of the sprint.
Why do the teams choose to work on multiple items at a time? There are several answers from the teams, examples being:
Item #2 is waiting for input from another team. That's why the developer started on a Spike.
The test is running. The pipeline takes a longer time to finish. In between the tester decided to build test cases and test data for item #6.
We are a group of efficient and experienced workers. For us, it is effortless to work on 2 to 3 items at a time.
The work items have minor works, we can finish them all side by side.
What problems do these situations lead to?
More efforts put by the team to accomplish the work.
The poor quality of output produced. (More bugs disrupting future sprints.)
An uneven amount of output over the sprints. (Amounts to lower predictability of the team.)
A few engineers or the entire team working beyond their work hours to keep the commitments.
Bigger sprint failure in an event of unplanned availability of the engineers.
WIP limit is the answer to avoid potential Sprint and output failure.
Work in progress (WIP) limits restrict the maximum amount of work items in the different stages of the workflow.
A common voice heard from teams:
"My team can't have WIP. We have individual experts in their areas, and they are also instrumental in multi-tasking. They can easily work on 3 stories at a time."
But we must understand that multitasking is not Free.
One of the great advantages of implementing WIP is to discipline the team members towards focusing on one thing at a time. Context switching is certainly not free.
A best practice originally from Kanban, limiting the WIP, can easily be mapped to other development methodologies like Scrum.
The theory of WIP is easy to read/share but difficult to implement. And, it is very difficult to get into the work culture.
I am a fan of WIP. Trying to learn how to effectively implement it in a team in a shorter lead time. Well, Yes - this all depends on the company's culture, thoughts of the people, and approach of the leader.
The implementation of WIP limits allows you to complete single work items faster, by helping your team to focus only on current tasks.
Here are a few benefits of implementing WIP limit in a team:
Enables to Manage Capacity.
Encourages to Practice Systems Thinking
Helps Identify Opportunities for Process Improvement
Improves throughput.
Introduces Slack into the System
If each team member is at 100% utilization, that means they cannot collaborate with the team, respond to questions, or help each other deliver work across the finish line. 100% utilization simply means that everyone is impossibly busy. Not a healthy habit for a team.
WIP limits add System Thinking by forcing us to prioritize, plan, and complete work; and work as a team.
My most favorite benefit of implementing WIP limits is, it introduces slack to the system.
In Kanban, underutilized time is referred to as slack time, and it’s seen as a sign of a healthy system. When you have team members not working on anything may use the slack time for improving the process. Team members can use the slack time to implement CI/CD, learn new skills, or brainstorm ideas to optimize recurring programs. They can organize their boards and backlogs, update outdated knowledge capsules, or do anything else that is important, valuable and that can enable the team to be more effective.
With implementing WIP, we can promote a healthy team culture with good practices that lead to a high-quality product and lead to happy customers. WIP is win-win for all. Always remember, our target is to maximize the values, not just the throughput. About the throughput, we have to find ways to optimize it, that will lead the predictability and build the stakeholders’ trust in the team.
What should be the WIP limit for my team?
If you ask me, the ideal WIP limit is one for any team. 😊
If the entire team can focus and contribute to the highest priority item from the backlog, we can get it in progress, work on it with everyone’s input, move it across the line to DONE and then pick the next priority item to work on.
The world is not that ideal most of the times, so use a formula and cross your heart for not crossing the limit unless you have a world drowning situation.
There are several formulae in word to determine a team’s the WIP limit. But the simplest (and most appropriate with above theory) is:
Round-down to the nearest whole number of: (Number of engineers) / 2
| Never distinguish tester, developer, lead, analyst on a team. They all are engineers |
Example #1: For a team of 6 engineeris, WIP limit should not exceed 6/2 = 3.
Example #2: For a team of 9 engineers, WIP limit should not exceed 4, since 4 is the nearest round-down number of 9/2 = 4.5 ~ 4.
Please mention your experiences with WIP limits, questions, thoughts and suggestions in the comments below.