Kanban
Kanban is a method for managing work as a continuous flow. The team visualizes its workflow on a board, limits how many items can be in progress at once and pulls new work only when capacity frees up. Instead of planning in fixed iterations, it focuses on finishing work smoothly and improving the flow over time.
How Kanban Works
The name is a Japanese word for a sign or signal card, used in Toyota's production system to trigger replenishment only when it was needed. David J. Anderson adapted the idea for software and knowledge work from 2004 and described the Kanban Method in his 2010 book. The Kanban Guide defines Kanban as a strategy for optimizing the flow of value through a process, using three practices:
- Defining and visualizing a workflow. Work items move across a board through columns that represent stages, such as Ready, In Progress, Review and Done. The team agrees explicitly what each stage means and when an item can move.
- Actively managing items in the workflow. The key control is a work-in-progress (WIP) limit: a cap on how many items can sit in a stage, or in the whole system, at once. When a column is full, the team helps finish existing work instead of starting more.
- Improving the workflow. The team uses data to find bottlenecks and change its process.
The guide names four flow measures:
- WIP: items started but not finished.
- Throughput: items finished per unit of time.
- Work item age: time elapsed since an unfinished item started.
- Cycle time: time from when an item started to when it finished.
Kanban has no required roles or fixed iterations, so a team can start with its current process and change it gradually.
Why Kanban Matters
Limiting WIP is the core insight. When a team juggles too many items, each one waits longer and context switching slows everything down. Capping WIP shortens cycle times, makes blockers obvious and makes delivery more predictable. Teams can forecast from throughput and cycle time history instead of estimates.
Kanban suits work that arrives unpredictably, such as support, operations and maintenance, and teams that release in a steady stream through continuous delivery. It is also a light starting point for small teams: agile for solo founders shows how WIP limits help one person ship smaller slices with less overhead.
Kanban Example
A four-person platform team handles a mix of feature requests and production incidents. Their board has columns for Ready, In Progress (WIP limit 4), Code Review (WIP limit 2) and Done. One week, Code Review hits its limit, so developers who finish coding cannot move their cards forward. Instead of starting new items, they review each other's work and clear the bottleneck. Over the next month, cycle time data shows reviews are the main delay, so the team agrees to keep pull requests smaller.
Kanban vs. Scrum
Scrum organizes work into fixed-length sprints with a Sprint Goal, defined accountabilities and set events. Kanban has no fixed iterations: work is pulled continuously as capacity frees up, and new priorities can enter at any time as long as WIP limits are respected. Many teams combine them, using a Kanban board and WIP limits inside Scrum sprints. Both are ways to apply agile principles.