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.