Why WIP limits?

October 22, 2021

The Work-In-Progress (WIP) limit is a concept made popular by the kanban development methodology. It’s a fairly simple concept. It’s simply a limit on the number of items that can exist at a given stage on a kanban board.

But why?

According to Atlassian, “WIP limits improve throughput and reduce the amount of work ‘nearly done’, by forcing the team to focus on a smaller set of tasks.” That’s true, as far as it goes. Humans are notoriously bad at multitasking, and procrastinating on a partly-done project is not efficient. But this explanation actually overlooks the main benefit that WIP limits provide.

WIP limits were first used in manufacturing, where human multitasking and procrastination were not the problem.

WIP limits were originally designed to identify operational bottlenecks, by making clear the difference between work in a waiting state and work actively being done.

Imagine a 3-stage process without WIP limits:

Stage two appears to have 6 items in progress. Is this because 6 items are actively being worked on, or has stage two over-committed? Let’s say stage two’s actual working capacity is only two items, so we impose a WIP limit of two:

With a WIP limit in place, it becomes clear that there’s a backlog of work waiting for stage 2 to become available. Stage 2 is a bottleneck for the system. If the goal is to improve throughput, we should examine this stage to find ways of improving it. Perhaps the capacity can be increased by hiring more people or investing in more equipment. Or perhaps a new process can be implemented to make the existing staff and equipment faster.

This is the real power of WIP limits: To show you where your bottlenecks are, so you know where to focus your improvement attention.

Related Content

How should we choose our WIP limits?

Start with a WIP limit equal to the number of people working a stage times a small number, such as 1.5 or 2. Then adjust up or down as necessary.

Pick a methodology: Scrum, Kanban, XP, Lean or DevOps?

None of these items directly replaces or conflicts with any of the others. In fact, you can use them all simultaneously.

Why "Agile Scrum" is an oxymoron

Whether you choose Scrum, Kanban, Lean or any other framework, if you only do that, you're not being agile.