Why WIP limits?

October 22, 2021
WIP limits help point out bottlenecks in your process, so you know where to focus attention for improvement.

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.

Share this

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.

How do I keep my devs busy while waiting on code review?

Don't worry about devs not having enough work. Worry on flow through the system.

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.