Kanban is a flow-based method for managing work. Unlike Scrum, it prescribes no roles, no iterations, and no ceremonies. It starts with what you do now and improves incrementally.
The name comes from the Japanese word for “signboard” — Toyota used physical cards to signal capacity in manufacturing. Software Kanban was formalised by David J. Anderson.
Core Practices
- Visualise the workflow — make all work visible on a board (To Do → In Progress → Review → Done)
- Limit work in progress (WIP) — cap the number of items in each column
- Manage flow — monitor and optimise how work moves through the system
- Make policies explicit — define what “ready” and “done” mean for each stage
- Implement feedback loops — regular reviews of the board and metrics
- Improve collaboratively, evolve experimentally — small, evidence-based changes
WIP Limits
WIP limits are the single most important practice. Without them, a Kanban board is just a to-do list.
Why they matter:
- Multitasking destroys throughput — context switching costs 20–40% of productive time
- WIP limits force finishing before starting, which reduces cycle time
- They expose bottlenecks: if a column is always full, that stage needs attention
How to set them:
- Start with number of people in each stage + 1 buffer
- Observe and adjust. Too high = no effect. Too low = people idle (sometimes that’s fine — it surfaces problems)
- A WIP limit of 1 per person is ideal but rarely achievable initially
Flow Metrics
| Metric | Definition | Why it matters |
|---|---|---|
| Lead Time | Time from request to delivery | Customer-facing measure of responsiveness |
| Cycle Time | Time from work started to delivery | Team-facing measure of efficiency |
| Throughput | Items completed per time period | Capacity indicator for forecasting |
| WIP | Items currently in progress | Leading indicator — more WIP = longer cycle times |
Little’s Law: Cycle Time = WIP / Throughput. Reduce WIP to reduce cycle time.
Use cumulative flow diagrams (CFDs) to visualise these metrics over time. Expanding bands indicate bottlenecks.
Kanban vs Scrum
| Kanban | Scrum | |
|---|---|---|
| Cadence | Continuous flow | Fixed sprints |
| Roles | None prescribed | PO, SM, Developers |
| Planning | Just-in-time | Sprint Planning |
| Change | Items can be added anytime | Wait until next sprint |
| Metrics | Lead time, throughput | Velocity |
| Commitment | Per-item | Per-sprint |
| Best for | Support, ops, continuous delivery | Feature development with regular releases |
They’re not mutually exclusive — many teams use “Scrumban” (sprints + WIP limits + flow metrics).
When to Use Kanban
Good fit:
- Support and maintenance teams with unpredictable work
- Ops / SRE teams handling incidents and requests
- Teams already doing continuous deployment
- Work where priorities shift frequently
Poor fit:
- Teams that need the structure of timeboxed iterations
- Organisations that measure progress in sprint velocity
- Early-stage teams that benefit from Scrum’s explicit roles and ceremonies
Anti-Patterns
No WIP limits — a board without WIP limits is just a to-do list on a wall. It won’t improve flow.
Invisible work — if work isn’t on the board, it doesn’t exist. Side projects, meetings, and support requests all consume capacity.
Zombie cards — items that sit in a column for weeks. Set aging policies and escalate or kill stale items.
Ignoring blocked items — blocked work consumes WIP capacity. Make blockers visible (red flag, separate lane) and resolve them urgently.
Links
- Kanban Guide for Scrum Teams
- David J. Anderson — Kanban (book)
- Scrum — alternative iteration-based framework
- Agile — the values underpinning both approaches