Kanban: Flow Over Iteration

KanbanKanban is often taught as "Scrum without the ceremonies," which gets the relationship backwards. Kanban wasn't derived from Scrum at all — it comes from a manufacturing discipline decades older than either — and the single most useful thing to understand about it is the structural difference: Kanban has no fixed iteration and no prescribed roles, because it was never designed around batches to begin with.

Origins: Toyota, Not Software

TheThe word kanban (看板) means roughly "signboard" or "visual card," and the system originates with Taiichi Ohno's work on the Toyota Production System from the late 1940s into the 1950s¹. Toyota's problem was inventory: post-war Japan couldn't fund the large stockpiles of parts that American manufacturers held, so Ohno needed production to run on just enough material, pulled through the line only as it was actually needed rather than pushed ahead of demand. The idea he adapted came partly from observing how American supermarkets restocked shelves — a customer takes an item, and only that consumed item gets replenished, not a fixed schedule of restocking regardless of what actually sold. A physical card (the kanban) travelled with each parts bin and authorised its replenishment only when the bin was empty: no card, no new work started. That's a pull system — work is pulled downstream by actual demand, not pushed by a plan made in advance.

David J. Anderson adapted this thinking to knowledge work — specifically software and IT operations teams — in the 2000s, and formalised it in his 2010 book Kanban: Successful Evolutionary Change for Your Technology Business, still the standard reference for Kanban as applied to software delivery². Anderson's contribution wasn't inventing new mechanics — it was showing that the same pull-based, WIP-limited discipline that worked on a factory floor applies directly to a queue of tickets on a board, and that it could be introduced as an evolutionary change to an existing process rather than a wholesale replacement.

Core Mechanics

Mechanism	What it does
Visual board	Columns represent workflow states (e.g. To Do → In Progress → Review → Done); cards represent units of work moving left to right
WIP limits	Each column caps how many cards may sit in it at once, forcing the team to finish work before starting more
Pull system	A card moves to the next column only when there's capacity there — work is pulled forward, never pushed onto an already-full stage
Cumulative flow diagram	A stacked area chart of how much work sits in each state over time, used to spot a growing bottleneck before it becomes a crisis

WIPWIP limits are the mechanism that makes the rest work. Without a hard cap on work-in-progress, a board is just a to-do list with nice columns; the limit is what forces the team to swarm on finishing an item that's stuck rather than starting something new and more interesting. This is the same instinct behind "stop the line" in the Toyota Production System — a blocked item is everyone's problem immediately, not a note for the next planning meeting.

The Real Contrast With Scrum

ThisThis is the distinction worth getting exactly right, because it's usually blurred into "Kanban is more relaxed Scrum," which understates a structural difference:

	Scrum	Kanban
Iteration	Fixed-length Sprint (a timebox); work is batched into it	None — continuous flow, items move individually as capacity allows
Roles	Prescribed: Product Owner, Scrum Master, Developers	None prescribed — Kanban overlays onto whatever roles already exist
Planning cadence	Batched at Sprint Planning	Continuous — replenishment happens whenever the backlog end of the board has capacity
Core control mechanism	The Sprint Goal and Sprint Backlog commitment	The WIP limit on each column
Change mid-cycle	Discouraged inside a Sprint — the Sprint Backlog is meant to be protected	Fully expected — there's no cycle boundary to protect; priorities can shift and the next pulled card simply reflects that

Put plainly: Scrum is a batch-and-queue system — it takes a chunk of work, timeboxes a period to do it, and inspects the result at fixed intervals (see Scrum). Kanban is a continuous-flow system with no batches and no timebox at all — every card moves at its own pace, gated only by the WIP limits of the stages ahead of it. That's why Kanban suits work with unpredictable, continuously-arriving demand (support tickets, ops incidents, a maintenance team) better than Scrum's Sprint structure does, while Scrum's fixed cadence suits work that benefits from a regular checkpoint for stakeholder review and re-planning.

Because Kanban prescribes no roles, it's also the framework most often layered on top of another one rather than used standalone — teams frequently run "Scrumban," Scrum's roles and Review/Retrospective cadence with Kanban's continuous board and WIP limits replacing the Sprint Backlog's rigid batch. This is one of the more common forms of the blending discussed in Hybrid Waterfall/Agile and Agile-Inspired Reality.

Practical Tools: GitHub Projects and GitLab Boards

BothBoth major hosting platforms have a native Kanban board built directly on top of their issue tracker, and it's worth using the real thing rather than a separate tool, since the board then stays attached to the actual work items. GitHub calls it Projects (a board view over issues, with a Status field driving the columns); GitLab calls the equivalent Issue Boards (driven by labels rather than a dedicated status field, but functionally the same idea). Either way, the columns need to be more than a bare "Open/Closed" — that's not a Kanban board, it's just an issue list with a coat of paint.

To make this concrete rather than abstract, here's a real, small board — a fictional room-booking project (the same one used in the Work Breakdown Structure and Gantt Charts pages), built specifically as a teaching resource: github.com/PatParslow/kanban-board-demo.

Six columns, not two: Idea (not yet scoped, might not happen), In Design (being specified before work starts), To Do (scoped and ready to pull), In Progress, Review, and Done. This is set up as a GitHub Projects Status field with those six options rather than the two GitHub ships by default (Todo/In Progress/Done) — the extra columns exist because "not yet scoped" and "being designed" are genuinely different states from "ready to build," and collapsing them loses exactly the information a board is for.

Labels do complementary work alongside the board columns rather than duplicating them — they answer "what kind of thing is this?" (bug, enhancement, documentation) rather than "where is it in the workflow?":

Notice this issue carries both an enhancement label (what kind of work it is) and an in-design label (a second, independent signal that happens to echo the board column it's currently sitting in) — the two aren't the same field, and a real setup only needs the board's own Status to drive columns. Labels are more useful reserved for the dimension the board isn't already showing: type of work, priority, or which component it touches, so filtering by label ("show me only bug cards") slices across the board a different way than the columns themselves do.

GitLab's Issue Boards work the same way conceptually, with one real difference worth knowing: GitLab boards are driven by labels rather than a dedicated status field, so a GitLab board's columns are themselves just labels (a workflow::in-design label, say) that the board displays as a column and automatically re-labels an issue when a card is dragged between them. Functionally equivalent outcome, different underlying mechanism — worth checking which one a given tool actually uses before assuming "the board" and "the labels" are two separate things, because on GitLab they're the same thing wearing two different views.

See Also

ForFor the fixed-iteration framework Kanban is most often contrasted with, see Scrum. For the broader lean thinking Kanban is one expression of, see Lean Software Development. For the philosophy both frameworks implement, see Agile: Origins and the Manifesto.

References