Updated and expanded
You can get an updated and expanded version of this post, and a comprehensive guide to project risk management, on the Boost website.
- Updated post: Limiting work in progress to manage project risk
- Comprehensive guide: Project risk management with Agile
Reducing risk by limiting work in progress
Limiting working in progress (WIP) shortens the lead time for features. It reduces context switching and batch size, greatly improving productivity.
Limiting WIP also helps the team and individual team members achieve higher quality by concentrating resource and attention.
What is the problem?
Teams and organisations often find themselves 'thrashing' - working very hard on a large number of items or projects without making progress.
It is impossible for us to determine the quality of work that is very nearly finished rather than completely finished. And failure to limite WIP typically results in an increase in defect rates.
Teams face integration problems as they work to incorporate many pieces of work at one time. It is difficult to determine how a new piece of functionality will interact with the product when there are many other pieces of work partially completed.
The time it takes for work to progress from start to finish is longer than the organisation or market can bear, making it harder for the organisation to capitalise on innovation and effort.
What does limiting WIP mean?
Limiting WIP is the process of reducing the number of work items that are in progress at any one time. For an organisation, this may mean limiting the number of projects in development. At the team level, this may mean working on one feature at a time.
We often see too much work in progress even within mature Agile teams. My experience is that this is much more prevalent in Scrum teams than Kanban teams. With Scrum teams, it's common to see all the stories for the current sprint (iteration) in progress.
This can occur for a number of reasons. It could be that a story gets 'blocked' and the team member has to wait for an external problem to be resolved. The team member may then decide to start a new story. Or it could be that the team member gets to a particularly tricky part of the work and decides to put it aside and start something new, with the intention of coming back to the original piece of work later.
This is inevitably a sign that the team will not complete the sprint within the iteration. The team is thrashing between pieces of work and is struggling to finish anything completely.
When the team implements WIP limits, there are a number of benefits:
- The team usually decides to work from the highest priority stories to the lowest, which lets them deliver the most value possible in the sprint.
- The team starts to collaborate more to complete features. Work is taken right through to 'Done' before the team moves on.
- The team completes any integration needed for each story. Any subsequent work need only integrate with the current state of the product.
- Work flows through the team more quickly.
Why is limiting WIP important?
Limiting WIP is important because, as the Agile Risk Management Model shows, it has an impact on time and quality. We can shorten the lead time for features, reduce context switching and batch size to improve productivity, and concentrate the team's resource and attention.
Reducing cycle time
You will find that an immediate benefit of introducing WIP limits is a decrease in the cycle time. Cycle time is the time it takes from work entering the system to work being completed. Because the team is more productive due to having less WIP, the work flows faster through the system.
Limiting WIP and visualising WIP help the team identify and address bottlenecks in their processes and redistribute resource as needed, further enhancing the flow of work through the system.
When we do not limit our WIP, we are often caught context switching - putting down one piece of work to pick up another. In knowledge work, this is especially time consuming.
It's like reading a number of books at the same time and constantly putting one down and picking up another. Each time we switch books we must load back into our mind the characters, the plot and where we are in the story. It is much quicker to read five books sequentially than to read five books simultaneously. Our quality of understanding of the book and enjoyment of the process is much higher.
Research shows that even if an individual reports higher productivity when multi-tasking, in reality they lose productivity.
A person who works on more than one project incurs a cost at each shift from one project to the other. The primary cost is the time required to change context. We know that simple interruptions like a phone call can cost as much as 15 minutes of recovery time. The more complex the task, the more time it takes to make the shift.
The teams I have worked with all report much higher levels of satisfaction when they work on a single project rather than try to juggle two or more. In fact, they report higher levels of satisfaction and productivity when working on one feature at a time.
Limiting WIP produces a faster cycle time for work through the team, program, portfolio and organisation. The faster our cycle time, the less we see wasteful and negative behaviours and consequences.
This post is an excerpt from the chapter on limiting work in progress in my book Risk to Reason: Managing Project Risk with Agile.