Kanban Guide

≡

Limiting Work in Progress

Work in Progress Limit

Limiting WIP (work in progress) is a characteristic feature of Kanban - it is of paramount importance to why the method works so well. When you first think about it, it may seem counter-intuitive. Are we telling people to work less? No - limiting WIP doesn’t mean limiting work itself, but limiting how many tasks can be started all at once.

What is “work in progress”?

Kanban came from manufacturing. Typically, manufacturing businesses keep a production inventory: a list of levels of materials and supplies in stock for use in the process. There are normally three types of inventory:

  • Raw materials: building materials, to which no work has yet been applied.
  • Work in progress: materials that have had some work done on them, also referred to as semi-finished goods.
  • Finished products: materials, work on which has been completed, and they are ready to be sold.

Why is limiting WIP considered a good thing, and should it be?

The predominant reason for WIP limits having a good influence on a workflow is that it speeds up task completion – it reduces both the lead and the cycle times, due to several factors. But one of the elementary reasons was to do with accounting purposes, as you will see in the example below.

Example Let’s consider WIP limits at a small software development house: a team of 4 takes in the customer requirements/user stories, conceptualizes and verifies the design, writes the code, tests it, and deploys it for the customer to use. They normally release around 20 stories each month. But besides the 20 deployed features, they’re also left with around 10 items partially completed, in various states of progress.

Although these unfinished items cannot be delivered, the company accountants cannot just write them off and not recognize them at all, as this wouldn’t be an accurate representation of work done during the month. Hence, the accountants accept the unfinished items as a form of an asset, and the company banks that value as something positive. We can see how that can make sense.

Business owners sometimes feel that the more WIP they have, the better. They trust that it’s only a matter of time before they will sell those, so unfinished work is correctly recognized as an asset. But the problem is - what happens when the work in progress time prolongs further and further? What if there are problems with specific features operation or integration to the product, and these WIP items never get released - does it still make sense to see them as assets? Are they bringing value to the software house?

You’ve probably heard people say that “Cash is King” - this tends to be true. Companies will often go under due to poor cash flow. It’s not always important how many assets a company has if it can’t convert them to or otherwise generate the cash when it’s needed. It will go broke, and all assets will be lost or sold for far less than what they’re worth. This is the problem with work in progress. It’s one thing for a company to recognize the WIP as an asset, but the fact is, those objects are unsellable. No one wants to buy a half-working piece of code, and if somebody does, then they’re probably looking to buy it for a whole lot less than a finished product price.

Eli Goldratt, a successful businessman and management guru argued that work in progress should not be regarded as an asset, but an expense. He argued that no one goes into business with the hope of just “staying busy”, companies need to make a profit. The only way you make a profit is by selling your product, and your production cost must be smaller than your total sales. Goldratt created a concept known as Throughput Accounting.

The concept singles out throughput (the speed with which an item can be built and delivered), inventories, and operating expenses as three main measures of productivity constraint. He formalized his thinking into a book “The Goal” and later into a system known as the theory of constraints. Companies that implemented this system experienced dramatic bottom-line improvements.

Why should we limit work in progress?

1. To foster a culture of finishing work, reduce time to market, and minimize risk

Your profit lies in the finished goods, not in WIP. And if you’re running a cash tight business - do you want to have 30 items halfway through to being sold, or rather 10 items ready to go? It’s always better to focus on fully realizing 10 elements and releasing them. That’s what limiting work in progress helps to achieve. If a company can only sell 10 items per month, there is no point in working on 30. A limitation of WIP here would be to focus on getting those 10 items done. So, if you limit WIP, you can easily focus on getting the begun work completed, and the sooner you can finish the work, the sooner you can deliver it to the client, and monetize.

With regards to WIP limits having an impact on project risk reduction, just imagine that if several items are in progress at the same time, it will be impossible to test their compatibility with the working product, as well as with one another. Hence, there is a high risk that the team will have to rework all the new components, rather than just test and integrate the newly completed one with the finished product.

What’s more, limited WIP also better facilitates any expedited work and can potentially make it less common an occurrence! When an issue arises, a team working on 3 features will pause them, and address the problem. So just 3 tasks will be slightly delayed. Had they had 20 items ongoing, all 20 would have been paused and delayed. And the more delayed items a pipeline has, the more likely the stakeholder is to ..expedite more work, to get at least one item done quickly, rather than keep on waiting. It’s therefore far preferable to focus on keeping short cycle times, deliver often and quickly, and expedite fewer tasks. Such - truly Agile - approach will make your workflow both sustainable and responsive to changes.

2. To minimize multi-tasking, chaos, idleness, and meetings

Limiting WIP quiets the noise and helps to manage the chaos. If I threw one ball at you, you would catch it quite easily. Then if I threw another shot at you, you’d also catch it. If I threw two balls at you at the same time, well, possibly you’d catch them both, or drop them both. But what if I threw 10 balls at you all at the same time? You would likely drop them all - chaos. For the same reason, multitasking is a fallacy - you can either work on one or two items and get them done quickly or work on 10 items and have nothing to show for it, or in other words: catch 2 balls or drop 10.

By limiting WIP, you’ll be making multitasking harder to come by, just as much at the individual level, as at the combined team focus level. And it should be fairly easy to understand why maintaining an even focus on one task vs. switching between 4 tasks, means overall better work quality. Setting up a Kanban board with WIP limits also tends to reduce employee idleness - for as long as there are always enough items in the backlog for all available team members.

Another aspect of WIP limiting is the possibility of tackling the number of different projects that the entire company is working on, though keeping tabs on how many projects each team can have at a time. Through these multi-level constraints, you can ensure that managers are aware of how much work can be taken on, and if more work is added, what other projects may suffer a cost. Tied to the limited number of projects at any time, is the fact that the fewer pies each worker has their finger in, the fewer meetings they need to attend, so another waste reduction for you! Add to it the fact, that Kanban boards visual nature itself diminishes the importance of status meetings - since all you need to know about a project is already on the board - and you may be able to get away with as few monthly meetings as one or two.

3. To maximize throughput, exercise a true pull process, and reduce batch sizes

Thanks to starting work only on what can be finished, you are ensuring the process running at its highest possible material throughput. That means less waste and more sales. Furthermore, by forcing the team not to start work while previous items are still in progress, you’d be implementing a true pull process model: not pushing work into the process, regardless of whether it can be handled or not, but letting the team pull new work in when it’s ready for it.

Maximizing throughput will visibly shorten the cycle time – the time it takes for one item to get from “Started” to “Done”, which will, again, help you to deliver new releases regularly.

Limiting work in progress can be of great help with reducing the product batch/sprint size because when teams come to settle on working on no more than, say, 1 task per person at a time, this spirals up to the project manager not planning for more than a set number of tasks per each sprint or batch. Of course, it does not always have to work that way, and WIP limits alone won’t ensure smaller batch sizes, but they do help with keeping them low.

WIP limits and identifying the bottlenecks

Although limiting WIP is good, if we apply WIP limits everywhere along the process, several other problems may arise. Applying a limit in the wrong place can lead to waste all around. If a manager limits work in progress in a bad way it could lead the company to produce fewer items than it is capable of. This too would be a waste and not something that Taichi Ōno would approve of. So how do we identify where in the process work in progress should be limited?

Deciding on the right WIP limit, through finding the true bottleneck

Example

There are four people in a software development team:

  • John finalizes the customer user stories, conceptualizing them into features.
  • Anton and Alice write the code.
  • Peter tests the code and signs it off as complete.

John picks out and delivers 10 user stories every week. Anton and Alice can usually code 8 stories a week, and Peter can test around 6 items a week. This shows, that the team can release 6 features per week, that is its throughput.

But if the team was told to work at its highest capacity, what would the situation be at the end of the week? We assume that each team member has enough work to start working on from the beginning. Let’s see how this could play out:

Identifying the true bottleneck - a WIP Limits Example

Remember, that WIP is an inventory item. We notice large stacks of user story cards at the Verified User Stories stage and under Coding. But why are items pilling up there? Because the tester is the bottleneck, the constraint of the process, able to only complete 6 verified releases per week.

What an Agile manager should do here, is limit the coding team to produce no more than 6 items a week, since anything more will be a waste, the tester could not handle the pace. Potentially, what could happen is for John, Anton, and Alice to jump in and help out Peter with testing, once they are finished with their tasks. This should improve the throughput of the system. Suddenly the company may be releasing more than 6 items a week, and employee engagement is improving along with throughput.

How to apply a WIP limit?

In summary, to apply a WIP limit appropriate to your process, you need to analyze it and find the slowest cog in the machine.

Step 1: Look at your process and identify bottlenecks

For a start, just walk your office or factory floor. Look around for team members who are overloaded and have a lot of inventory on their desks or visual boards. That’s how you will find your bottleneck!

Step 2: Match WIP limit to the capacity of the slowest process step

Go talk to the team working at the bottleneck step, and see how you can limit work to them, it will help your whole company work faster, and your employees will love you for it!

Step 3: Analyze the flow with the WIP limits applied periodically

As your process changes, the team grows, shrinks, or changes - the applied WIP limit may need adjusting. Keep an eye on it, to maintain your optimal throughput levels.

Summing up

Limiting work in progress is as simple a concept as it is efficient. Consider trying it with your team - or just for a personal workflow - and you will see it first-hand. To sum up, by constraining how many things you’re working on at any time, you will potentially see the following benefits:

  • Quicker task completion - reduced lead and cycle times, maximized throughput
  • Faster and more sustainable product delivery rates
  • Reduced project risk and quicker bottlenecks identification
  • Less multi-tasking, less employee idleness
  • Smaller batch sizes, fewer meetings, and better control over all of the organization’s projects

Further reading

2024-08-06 Kanban Tool https://kanbantool.com/kanban-guide/kanban-fundamentals/limit-work-in-progress