By Nick Butler
Tags: Agile , Development
Limiting work in progress (WIP) helps you manage project risk and deliver quality work on time. In this post we look at how limiting work in progress helps you make software development more rewarding for individual team members, and for your whole organisation.
To see how this works in the real world, take a look at this case study on how a project team went about reducing WIP to limit risk.
Focusing is about saying No.
Steve Jobs
As we covered in earlier posts, the four key Agile risk management tools are prioritisation, transparency, batch size and work in progress, and each of these reduce one or more of the most common risks: risks to quality, time, cost and value.
Get your complete guide to
Project risk management with Agile
Limiting WIP shortens the lead time for features. It reduces context switching and batch size, greatly improving productivity and helps the team and individual team members achieve higher quality by concentrating resource and attention.
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.
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.
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 the team member got to a particularly tricky part of the work and decided 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 completely finish any work.
When the team implements WIP limits, there are a number of benefits:
Limiting work in progress 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.
You will find that an immediate benefit of introducing work in progress 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 work in progress, the work flows faster through the system.
Limiting work in progress and visualising work in progress 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.
Context switching takes places at the team level as well as the individual. It’s easier for teams to collaborate on a limited number of tasks. For instance, having large amounts of work in progress tends to mean that discussions that developers have with Product Owners refer to work that they undertook some time ago, making it harder to recall the details.
Switching between a number of different tasks doesn’t just increase the time taken to complete the work, it also reduces the quality. Psychologist Stephen Monsell from the University of Exeter reviewed the studies on task-switching and found that people tend to be more error-prone immediately after a task switch.
Work in progress limits also encourage us to prioritise the work we choose to have in progress, concentrating our attention on the work that will deliver the most value. Find out about reducing software development risk with Agile prioritisation.
Having fewer pieces of work on the go tends to reduce the overall amount we’re working on. It also encourages us to complete one task before moving on to the next, ensuring you have potentially shippable software that delivers value as soon as possible. As a result, WIP limits are a good technique for reducing batch size.
WIP limits alone don’t ensure small batches. That’s because we tend to impose limits on the number of tasks or projects, which doesn’t take into the account their size. This means we need to focus on both limiting work in progress and reducing batch size. Find out how to reduce batch size in Agile software development.
Fill in the table below to see how your project or organisation is handling WIP.
Download your printable work in progress evaluation checklist (PDF)
| Practice | Yes/No |
| Teams have formal WIP limits in place | |
| My organisation limits WIP across the organisation | |
| My team measures and monitors the cycle time of work increments | |
| My organisation measures and monitors the cycle time of increments of value | |
| Teams pull work as capacity becomes available | |
| Teams visualise their WIP | |
| WIP limits are adjusted to reduce cycle time, as needed | |
| Teams focus on fully completing increments of work | |
| Teams integrate early and often |
Add up one point for every question to which you answered ‘yes’.
0-2 points: WIP is not being limited, made visible or measured, or you are not measuring the impact of limiting WIP. There are a number of small but effective measures you can take to begin harnessing the power of limiting WIP.
3-6 points: You are limiting, making visible and/or measuring WIP. You may already be seeing the benefits of reducing WIP, but you may not be measuring the impact or applying WIP limits as broadly as you could.
7-9 points: You have limited WIP in place and are likely to be seeing the benefits! Are there any more opportunities for you to limit or make visible WIP?
You need to visualise your work in progress in order to understand it. Agile teams commonly use Scrum and Kanban boards to visualise their work in progress. A Scrum board shows the work the team has planned for the sprint. The board is split into columns showing the status of the work: unstarted, in-progress or completed. This simple tool gives us a great deal of information about how the team is handling the work and how much work is currently in progress.
There is no hard and fast rule for how much WIP is best. Each team needs to determine this as they work together. In the example above, the team is halfway through a sprint. This team has historically struggled to deliver completed stories within the iteration, with stories often taking two or even three sprints to complete. We can see that there are a large number of stories in progress. The team is unlikely to finish many stories this sprint and this will result in a delay in delivering value.
It’s easy to see at a glance that only two stories are in progress, one for each developer. The Product Owner’s work in progress is also small, with only two stories completed and waiting to be accepted.
By making the amount of work in progress transparent, we can manage it better. Learn more about how Agile transparency reduces project risk.
If you have a visual workspace, you might like to try a technique called WIP limits. We often see WIP limits in place for teams using Kanban. A Kanban board has a number of columns signifying the steps, from starting to completion, through which each piece of work passes. At its simplest, the columns are Ready, In progress and Complete.
We can apply a WIP limit to a column as a tool for the team to ensure that they don’t maintain more than a certain level of WIP. In this example, we could apply a WIP limit of two to the In progress column. This would mean that we could only work on two items at a time. In order to pull more work into the In progress queue, we would need to finish one of the In progress items so that it could be moved to Complete.
As Don Reinertsen points out, WIP limits are the easiest way to match the rate at which teams work.
In many software packages that support Kanban boards the user has the option of using hard or soft WIP limits. A soft WIP limit will allow the limit to be exceeded and will have a visual indicator that this has happened. A hard WIP limit will not allow the number of items in the column to exceed the WIP limit.
An effective way to constrain the amount of WIP across an organisation or system is to apply local WIP limits. This works for small flat organisations as well as large enterprises. By applying WIP limits at the team level, this places a limit also on the WIP at the level above, whether that’s a program of work or a product.
You can also explicitly limit WIP at the organisational level. Doing this ensures you finish one project before starting another. Even in an ideal world where there is no cost from context switching between projects, an organisation working sequentially delivers more value.
Concentrating your resource on fewer projects mean they get finished sooner so they deliver value earlier. It also means you can apply lessons from recently finished projects to those next in line. And because there is less time between starting and finishing, your planning and technology choices are less likely to become out of date.
If work is not fully finished, it will need to be revisited later, increasing your work in progress at that stage. Work is fully finished when it meets all your quality standards, is integrated, documented and all loose ends are tied off. It helps to agree as a team on your Definition of Done.
Limiting work in progress produces a faster cycle time for work through the team, program, portfolio and organisation. The faster our cycle time, the less we see of wasteful and negative behaviours and consequences.
Let’s look at an example of the impact of a slow cycle time. With a slow cycle time, the team will have a large queue of work waiting to be started. This is because queue length and cycle time are related, according to Little’s Law (see Don Reinertsen’s Principles of Product Development Flow for an explanation and analysis of Little’s Law). Within organisations there are often individuals, business units or leaders who are able to request and receive expedited work. For example, when the CEO needs a photo of their niece on the homepage, this may jump the queue of other work and the team may begin work on it immediately.
We reduce the amount of resource available to be applied to work currently in the system when we expedite the new piece of work. This increases the cycle time for the team. As stakeholders see the cycle time increasing, they will start to expedite more work, jumping the queue and causing the cycle time to grow even longer.
The cycle reinforces itself until we see a catastrophic collapse in the system where only expedited work is being worked on. New work is being added to the system constantly, exceeding the systems capacity. In this scenario the WIP continues to increase until work hits a standstill.
How does a short cycle time avoid this? If a team’s cycle time is short, people needing work completed can see that the queue of work for the team is short (or at least manageable). When they need work done, they can see that putting it into the queue at the appropriate priority will see the work completed within a reasonable time frame, and they don’t feel the need to expedite the work.
Moreover, as Alan Shalloway points out in his excellent Scrum Alliance article, “working on too many things at once makes productivity go down and defect rates go up.”
As the defect rate goes up, motivation comes down. This also further slows throughput as time goes into fixing the bugs. Often the bugs are in stories that were completed some time ago, requiring context shifting when developers return to them. This creates a vicious circle, increasing the risk you’ll deliver late, and deliver low quality work.
Moreover, any defect is a security risk. Ensuring you include security validation in your definition of done and integration testing are among the ways you can manage security in Agile software development.
Reducing the amount of work in progress has an immediate and profound effect on the time it takes us to produce working software and the quality of that software.
Limiting work in progress reduces risk in projects in a number of ways. Firstly limiting work in progress reduces cycle time. This both increases trust and throughput of the team and reduces the risk of missed deadlines. Secondly, it minimises context shifting and the reduction in quality this causes.
In order to limit work in progress it is extremely helpful to visualise the work in progress. It’s then easy to see which stages of the process would benefit from the imposition of limits.
Constraining local WIP has the added benefit of constraining WIP globally. The benefits of these WIP limits then move out across the organisation.
Crucially, limiting work in progress not only makes your team more productive, it also makes the work more pleasurable.
| Guidance | Case studies & resources |
|---|---|
| Introduction to project risk management with Agile | Agile risk management checklist — check and tune your practice |
| Effective prioritisation | |
| Reduce software development risk with Agile prioritisation | Reducing risk with Agile prioritisation: IntuitionHQ case study |
| Increasing transparency | |
| How Agile transparency reduces project risk | Risk transparency: Smells, Meteors & Upgrades Board case study |
| Limiting work in progress | |
| Manage project risk by limiting work in progress | Reducing WIP to limit risk: Blocked stories case study |
| Reducing batch size | |
| How to reduce batch size in Agile software development | Reducing batch size to manage risk: Story splitting case study |
