What Is Kanban

A pull system, not a schedule

Kanban comes from the Toyota Production System, where a physical card (kanban, literally "signboard") signalled to an earlier stage of a factory line that capacity had opened downstream and it was safe to send more work forward. Nothing moved until there was room for it. David Anderson adapted the idea to software and knowledge work in the late 2000s, and the core mechanic survived the translation intact.

Where Scrum organises work into fixed-length sprints, Kanban has no cycles at all. Work simply flows across a board, one card at a time, pulled forward only when the next column has room. There's no sprint boundary to plan against and no fixed team roles to fill, which makes Kanban easier to adopt incrementally, and easier to run alongside whatever a team is already doing.

Why the WIP limit is the whole point

The counter-intuitive part of Kanban is that limiting how much work a team may start makes it finish more, not less. This follows from a simple relationship: on average, how long an item takes to get through the system is proportional to how many items are in the system at once, divided by how fast the system completes them. Add more in-progress work without adding completion speed, and everything already in flight takes proportionally longer to finish, including the item someone urgently wanted expedited.

A WIP limit forces that trade-off to be visible instead of hidden. When a column is full, starting something new means either finishing something first or explicitly deciding to break the limit, a decision that should be rare enough to notice when it happens, not routine enough to be background noise.

Reading a cumulative flow diagram

A cumulative flow diagram plots, over time, the running total of cards in each stage of the workflow, stacked as coloured bands. Read left to right, the bands should stay roughly parallel and similarly thick. That's a system where work enters and exits each stage at about the same rate.

A band that widens over time means work is arriving at that stage faster than it's leaving: a bottleneck forming in slow motion, usually well before anyone notices it by eye on the board itself. It's the single most useful diagnostic Kanban produces, precisely because it doesn't rely on anyone's impression of how busy the team feels.

Two numbers fall directly out of the same data: cycle time, how long a card takes from start to finish, and throughput, how many cards finish per week. Neither requires anyone to estimate anything. Both are just measured from timestamps already on the cards, which is what makes them harder to argue with than a status update.

Kanban versus Scrum, briefly

Scrum commits to a batch of work for a fixed sprint and reviews it at a fixed boundary; Kanban commits to nothing beyond the WIP limit and reviews flow continuously. Scrum assigns specific roles; Kanban assigns none. Neither is more disciplined than the other: Scrum's discipline is in the commitment, Kanban's is in the limit. Many teams end up running both: sprints for planned feature work, a kanban-style board with WIP limits for the support and maintenance stream that never really pauses.

One refinement worth knowing: classes of service. Not every card deserves the same treatment: a genuine production incident shouldn't queue behind routine work the way a normal request does. Kanban handles this with an explicit expedite lane rather than by informally letting people jump the queue, which keeps the WIP limit meaningful instead of quietly optional for anything urgent enough.

Where the tool fits

A WIP limit that's advisory rather than enforced tends to erode within a few weeks, quietly, as "just this once" repeats itself. ShipSprint's boards carry per-column WIP limits that are actually enforced, not just suggested, and new requests land in a triage inbox rather than someone's messages, which matters specifically for Kanban's pull model, since work that arrives through a side channel bypasses the limit entirely and defeats the point of having one.