Kanban fundamentals: WIP limits and the pull system

Most teams' idea of "Kanban" is a To Do / In Progress / Done board — genuinely useful for visualizing work, but that visualization alone is not what Kanban, as a method, actually is. The defining mechanic is a work-in-progress (WIP) limit: an explicit cap on how many items are allowed to sit in a given column at once. A board with unlimited "In Progress" capacity can visualize a team drowning in 15 half-finished things — it just can't stop it from happening, which is the entire point of the limit.

If "In Progress" is already at its limit of 3, nobody pulls a fourth item in — even if they've finished their current task and have nothing else queued. That forced idle moment is uncomfortable, and it's also the actual mechanism: it pushes people toward helping finish the items already in flight (reviewing a teammate's work, pairing on a blocker) instead of starting something new, which is how work-in-progress compounds instead of clearing.

This is the counterintuitive core of Kanban: starting less work finishes more work, faster. Multitasking between many simultaneous in-progress items has real, measurable costs — context-switching overhead, and every item sitting "in progress but not actually being worked on right now" while its owner is context-switched onto something else. Little's Law formalizes this: average time an item spends in a system equals the number of items in the system divided by the average completion rate. Fewer things in progress at once, for a similar completion rate, mechanically drops the average time any single item spends waiting to finish.

In a push system, work gets assigned to whoever has capacity, decided upstream, regardless of whether downstream stages can actually absorb it — a classic bottleneck generator, since work piles up in front of whichever stage is slowest. Kanban is a pull system: a person (or a stage) only takes on new work when they have actual capacity for it, signaled by an open slot under the relevant WIP limit. Work moves because someone downstream had room and pulled it forward, not because someone upstream decided it was time to hand it off.

This reframes what "blocked" looks like on a healthy Kanban board — a full column isn't a problem to route around by pushing more work into it; it's the exact signal that the team should be swarming to clear that column before starting anything new.

A cumulative flow diagram stacks the count of items in each column over time, making a growing bottleneck visually obvious well before it becomes a crisis:

If the "Review" column's band keeps widening week over week, that's a direct, early signal that review capacity — not coding capacity — is the actual constraint on how fast anything ships, well before someone notices "everything feels stuck in review" anecdotally.

Kanban tends to fit better than Scrum for work that arrives unpredictably and needs to be actioned continuously rather than batched — support/on-call queues, ops and infrastructure work, a small maintenance team fielding a steady trickle of bug reports. Scrum's fixed-length sprint with a committed scope assumes work can be reasonably batched and planned a sprint at a time; a queue that's genuinely reactive (a production incident doesn't wait for the next sprint planning) is a better fit for Kanban's continuous-flow model. The next lesson in this domain covers this choice — and the hybrid "Scrumban" — directly.