Kanban

Kanban is a lean and agile method for managing work by making it visible and limiting how much is underway at once. Every task becomes a card, and the cards move across a board whose columns represent the stages of your process — say, To Do, In Progress, Review, and Done. The rule that gives Kanban its power is the work-in-progress limit: each column can hold only so many cards, so the team finishes what it starts before pulling in more. Work is pulled, not pushed, which keeps people from drowning in half-done tasks. The word comes from Toyota's factory floor, where a physical card signaled when to restock a part. David Anderson later adapted the idea for software and knowledge work, and it now runs everything from engineering sprints to editorial calendars.

Kanban matters because it attacks the quiet killer of team output: too many things started and too few finished. When work in progress is capped, bottlenecks stop hiding. If cards pile up in the Review column, the board shows you exactly where flow breaks, and the team swarms that stage instead of starting new work. You measure how long a card takes to cross the board, its cycle time, and how many finish per week, its throughput, so improvement becomes concrete rather than a feeling. Unlike a rigid plan, Kanban is evolutionary — you start with your current process and improve it incrementally. A marketing team, for instance, can watch campaign briefs stall in legal review and fix that handoff, rather than blaming writers for slow delivery. The board turns invisible congestion into a problem you can see and solve.

Kanban and Scrum are both agile approaches, but they organize work differently, and confusing them leads to sloppy practice. Scrum runs in fixed timeboxes called sprints, usually one to four weeks, with a committed backlog, defined roles such as product owner and scrum master, and ceremonies like sprint planning and the retrospective. At the sprint's end you inspect a shippable increment and plan the next one. Kanban has none of that scaffolding by default. There are no sprints, no prescribed roles, and no reset — work flows continuously, and you pull the next card whenever capacity opens under the work-in-progress limit. Scrum asks, what will we commit to for the next two weeks? Kanban asks, what is the next most important thing, and do we have room to start it?

Choosing between them depends on your work, not on fashion. Scrum suits teams that can plan a batch of work and protect it from interruption for a sprint, such as a product squad building a feature. Kanban suits work that arrives unpredictably and must be handled as it comes — support queues, operations, editorial pipelines, or any team facing a steady stream of varied requests. Many teams blend the two into what practitioners call Scrumban, keeping a sprint cadence while adopting work-in-progress limits and a pull system. The key difference to remember is that Scrum changes your process into a prescribed framework, while Kanban overlays visualization and limits on the process you already have. One is a container you fill; the other is a lens you look through, and mixing up which you are doing muddles both.

Using Kanban well starts with an honest board. Map the real stages your work passes through, including the ugly ones like Waiting on Client or Blocked, because a board that hides handoffs hides your worst delays. Then set work-in-progress limits low enough to feel uncomfortable — the discomfort is the point, since it forces finishing over starting. Make policies explicit: what does Done mean for each column, and who pulls a card forward? Watch the metrics that matter, cycle time and throughput, and hold regular reviews to shorten them. Treat the limits as experiments you tune, not commandments carved in stone. A content team might cap In Progress at three articles per writer and discover that quality and speed both rise once no one is juggling six drafts at once, because attention stops fracturing across too many open tasks.

The traps are common. Teams build a board but ignore the work-in-progress limits, so Kanban becomes a to-do list with extra columns and none of the benefit. Others set limits so high they never bind, or so low that work starves. Some forget that Kanban is meant to drive improvement — they visualize the mess and then live with it, rather than using the board to fix the bottleneck it reveals. And many confuse activity with progress, celebrating a busy board while cards age untouched in a corner. Done right, Kanban is not about filling columns; it is about finishing work smoothly, limiting how much you carry, and steadily removing the obstacles the board exposes. The discipline is to respect the limits and act on what they show you, week after week.

Kanban comes from the Japanese word for signboard, the physical card Toyota used to signal restocking, later adapted by David Anderson for software and knowledge work.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where kanban is a core concern: