Keep work in flow: WIP limits
Starting work is easy and feels productive. Finishing work is what ships. WIP limits force the difference.
Key takeaways
- Starting work feels like momentum but isn't value — value is created only when work crosses the finish line and reaches a user — and a board full of started-but-not-finished work is a stalled team wearing a busy costume.
- A work-in-progress limit caps how many items can sit in a column at once, so you cannot start something new without first finishing, which inverts the default behavior from pulling new work to driving existing work to done.
- WIP limits make problems visible: a column that hits its limit and backs up is a flashing light pointed at your actual bottleneck, whereas without limits the bottleneck hides as work piles up invisibly upstream.
- Set limits low and raise them reluctantly, because a limit that's never reached is just a suggestion; when a limit hurts, fix the flow rather than raising the cap, and raise it only when you've genuinely added capacity.
Starting is not shipping
There is a seductive feeling of productivity in starting things. A new issue picked up, a branch created, a card dragged into 'In progress' — each one feels like momentum. But none of it is value. Value is created only when work crosses the finish line and reaches a user. A board full of started-but-not-finished work is not a productive team; it is a stalled one wearing a busy costume.
The trap is that started work hides the stall. Every column has cards in it, everyone is doing something, the activity charts look healthy. Meanwhile nothing is actually completing, because the team's attention is spread across a dozen half-built things, none of which is anyone's whole focus. Motion is not progress, and a busy board is the most convincing disguise stalled work ever wears.
What a WIP limit does
A work-in-progress limit caps how many items can sit in a given column at once. 'In progress' is limited to, say, three per person. The rule is brutally simple and its effect is profound: you cannot start something new if doing so would breach the limit. To start, you must first finish.
That single constraint inverts the team's default behavior. Instead of pulling new work whenever you are bored or blocked, you are pushed to drive existing work to done. When you hit a blocker, the limit means you cannot just start something else and forget the blocked thing — you are forced to deal with the blocker, because the slot stays occupied until the work moves. The limit converts the temptation to start into pressure to finish.
Limits make problems visible
When a column hits its limit and work backs up behind it, you have learned something. That column is your bottleneck — the actual constraint on how fast the whole team can ship. Without limits, the bottleneck hides, because work just piles up invisibly and everyone stays busy upstream pretending the pile is not there.
A backed-up column with a WIP limit is a flashing light pointed at exactly the thing slowing you down. Maybe code review is the constraint, or QA, or a single overloaded specialist. The limit does not fix the bottleneck, but it makes it impossible to ignore, which is the necessary first step. You cannot improve flow you cannot see.
Set them low, raise them reluctantly
The instinct is to set WIP limits high enough that they never bite, which makes them decorative. A limit that is never reached is not a limit; it is a suggestion the team ignores. Set them low enough to be felt — uncomfortably low at first — and let the discomfort teach you where the real constraints are.
When a limit hurts, the right response is usually to fix the flow, not raise the cap. If 'In review' keeps backing up, the answer is faster reviews, not permission to pile up more unreviewed work. Raise a limit only when you have genuinely added capacity, never just to relieve the pressure the limit was supposed to create. Keep work in flow, finish before you start, and the team ships more by starting less.