WIP Limits (Work In Progress Limits) are a constraint on the number of items that can be in a given stage of work at any time — a rule so simple, so obviously correct, and so universally beneficial that virtually nobody follows it.
The principle is elementary: finish things before starting new things. If you can only have three items in progress, you must complete one before pulling another. This creates flow — work moves through the system instead of accumulating in the middle. It prevents the gridlock that occurs when everyone starts everything and finishes nothing.
At Toyota, WIP limits are enforced by physics. A workstation can hold one car. When the car moves, the next car arrives. The limit is not a policy. It is a conveyor belt.
In software, WIP limits are enforced by agreement. Agreements, unlike conveyor belts, are flexible. “Just this once” is the three-word incantation that dissolves every WIP limit ever set.
The Escalation
WIP limits die the same death in every organization:
Day 1: The team agrees: maximum three items in progress per person. The reasoning is sound. The commitment is genuine.
Week 2: A production bug arrives. It’s urgent. The developer starts it without finishing their current work. WIP is now 4. “It’s a bug. Bugs don’t count.”
Week 4: A stakeholder requests a “quick look” at something. The developer opens the ticket, reads the code, starts a branch. Doesn’t finish. WIP is now 5. “I’m just investigating. It’s not really in progress.”
Week 6: The developer has seven items in various states of partial completion. Three have open PRs awaiting review. Two are blocked by other teams. One has been “almost done” for ten days. One was started this morning because the developer needed a break from the other six.
Week 8: Nobody mentions WIP limits. The board shows fourteen items in progress. The Scrum Master updates the board daily. The board is now a chronicle, not a constraint.
The WIP limit did not fail because the team lacked discipline. The WIP limit failed because software work is interruptible in ways that manufacturing is not. A car on an assembly line cannot be set aside while the worker answers a Slack message about a different car. A pull request can.
The Squirrel’s Natural State
The Caffeinated Squirrel is the natural enemy of WIP limits. The Squirrel’s preferred working mode is seven things simultaneously, each one exciting, none of them finished, all of them generating architectural proposals that start new work streams.
The Squirrel does not violate WIP limits through negligence. The Squirrel violates WIP limits through enthusiasm. Each new item is more interesting than the current one. Each context switch is an opportunity to propose a framework. The Squirrel’s WIP is unbounded because the Squirrel’s curiosity is unbounded, and curiosity does not respect conveyor belts.
The Lizard’s WIP limit is 1. Not as a policy. As a physiology. The Lizard does one thing. Then the next thing. The Lizard has never context-switched, because the Lizard has never started a second thing while the first thing was unfinished.
“Build the simple thing. Ship it. Let the gaps teach you.”
— The Lizard’s WIP policy, observed across the lifelog
Why They Matter
WIP limits matter because they are correct.
The math is unambiguous: reducing work in progress reduces cycle time, increases throughput, and improves quality. This is not opinion. This is queueing theory. Little’s Law states that cycle time equals WIP divided by throughput. Reduce WIP, reduce cycle time. The law does not negotiate.
Every developer knows the feeling of finishing a day with twelve things started and nothing completed. Every developer knows the opposite feeling: finishing one thing, shipping it, starting the next. The first day is exhausting. The second day is productive. The difference is WIP.
WIP limits are the right answer. They are also the answer that requires saying “no” to new work, which requires telling a stakeholder “not yet,” which requires organizational courage, which is the scarcest resource in software — scarcer than developers, scarcer than budget, and considerably scarcer than JIRA tickets.
