Kanban

How Kanban Works

Kanban, derived from the Toyota Production System, organizes work around a visible board where tasks move through columns representing stages of a workflow. Unlike Scrum, there is no sprint cycle, no planning event, and no committed backlog. Work enters the system continuously, gets processed, and exits when done. The goal is to make this flow as smooth and fast as possible by removing the bottlenecks that slow work down.

The word kanban comes from Japanese, meaning sign or signboard. In Toyota’s original system, physical cards signaled when to produce or replenish inventory. In knowledge work, the visual board serves the same function: making the state of all work immediately readable without a meeting or a status report.

Visualize the Work

Everything a team is working on, waiting to work on, or waiting to release appears on the Kanban board. Invisible work is unmanageable work. Teams that track work in email, in conversations, or in their heads cannot see where tasks are accumulating or where work is stalling. The board forces all work into a single shared view.

Each column on a Kanban board represents a stage: typically Backlog, Ready, In Progress, Review, and Done at minimum. Teams customize columns to match their actual workflow rather than a prescribed structure, which makes Kanban adaptable to support queues, design reviews, legal approvals, and any other stage-based process.

Limit Work in Progress

WIP limits are numeric caps on how many tasks can be in a given column at once. Setting a WIP limit of three on In Progress means that when three tasks are in that column, no new work can start until one moves to Review. This forces team members to finish current work before starting new work, which sounds counterintuitive but consistently produces better throughput than letting everyone start multiple tasks simultaneously.

WIP limits also make bottlenecks visible immediately. If Review has a limit of two and both slots are always full, the bottleneck is in the review process. Teams can see this without a process audit and address it directly rather than discovering it at a retrospective weeks later.

Manage Flow

Flow management means tracking how smoothly work moves from entry to exit and improving that movement over time. The primary metrics in Kanban are cycle time (how long an item takes from start to done), throughput (how many items are completed per unit of time), and work item age (how long items have been in the system without being completed). Teams use these metrics to identify where work stalls, not to measure individual output.

The Six Core Kanban Practices

The Kanban Method, formalized by David J. Anderson in 2010, defines six practices that distinguish it from simply using a visual board. The first two (visualize and limit WIP) are foundational. The remaining four enable sustained improvement.

Manage flow by tracking how work moves through the system and removing obstacles to smooth movement. Make policies explicit by defining clear rules for each stage: what does it mean for work to be Ready? What constitutes Done? Explicit policies reduce ambiguity and enable consistent handoffs between team members. Implement feedback loops through regular meetings at different cadences: daily standup for operational blockers, weekly replenishment meetings for backlog priority, and monthly retrospectives for process improvement. Improve collaboratively and evolve experimentally by making small, measurable changes to the process and evaluating their impact before making further changes.

When Kanban Works Well

Kanban is the better fit when work arrives continuously and cannot be batched into fixed iterations. IT support queues, product maintenance work, customer success operations, and marketing content production all follow this pattern. Work items vary in size, priority shifts constantly, and the team cannot predict what will arrive in the next two weeks with enough reliability to commit to a sprint.

Kanban also works well for teams that want to improve their process without adding ceremony overhead. Scrum requires three roles, four events, and three artifacts. Kanban requires a board and WIP limits. Teams that struggle with the overhead of Scrum ceremonies but still need a structured approach to managing work often find Kanban a better fit.

Mature Agile teams sometimes migrate from Scrum to Kanban as their delivery process stabilizes. When a team’s stories are consistently small, their Definition of Done is solid, and their stakeholder relationships are stable, the sprint structure adds overhead without adding value. Kanban allows them to maintain continuous delivery without the ceremony of sprint boundaries.

When Kanban Struggles

Kanban struggles when teams need to commit to a specific set of deliverables by a specific date. Without sprint boundaries and sprint goals, Kanban provides no natural forcing function for commitment. Teams can manage flow efficiently while still failing to deliver what stakeholders need by a given date, because there is no event that surfaces that risk the way sprint planning and sprint reviews do.

Kanban also requires more process maturity than Scrum. Scrum’s prescribed events force teams to inspect and adapt on a regular schedule. Kanban’s feedback loops are optional and only as effective as the team’s commitment to running them. A Kanban team with no replenishment meeting and no retrospective is a team with a visual board and no process, which is worse than either Scrum or Kanban done correctly.