Visualise the flow, limit work in progress, and improve continuously — without fixed sprints. Born in Toyota's factories, adapted for software. Where Scrum optimises for learning, Kanban optimises for flow.
▸ Try the interactive toolKanban is a visual workflow-management method that helps teams manage and improve the flow of work continuously — without fixed-length sprints. It originated in Toyota's manufacturing system and was adapted for software. Where Scrum optimises for learning through time-boxed iterations, Kanban optimises for the smooth, continuous flow of work.
Its core practices are deceptively simple: visualise the workflow on a board (columns for each stage), limit work in progress (WIP limits per column), and manage and improve flow (measure cycle time, find bottlenecks). The most counterintuitive and powerful of these is the WIP limit: by restricting how much work can be in progress at once, Kanban actually increases throughput — because starting less means finishing more, and bottlenecks become immediately visible.
Visualise the workflow (a board, one column per stage)
Limit WIP (a cap on items in each stage)
Manage flow (measure cycle time, attack bottlenecks)
Pull-based and continuous — no sprints.
The instinct under pressure is to start more work to show progress — which is exactly backwards. Kanban's WIP limits enforce the counterintuitive truth that finishing beats starting.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Too much work in progress | Everything's started, nothing's finished; context-switching kills throughput. | WIP limits force finishing before starting, raising real throughput. |
| Invisible bottlenecks | Work piles up unseen at one stage, stalling everything downstream. | A visual board makes bottlenecks immediately obvious. |
| Forcing sprints onto flow work | Time-boxes fit poorly for support, ops, or continuous delivery. | Kanban suits continuous flow without artificial sprint boundaries. |
| Optimising for busyness | Everyone busy on something looks productive but delivers little. | Flow metrics measure delivery, not activity. |
Map your actual stages as columns (e.g. To Do → In Progress → Review → Done) and put every work item on the board. Seeing the whole flow is the foundation.
Cap how many items can sit in each column at once. This is the heart of Kanban — the limit forces the team to finish in-progress work before pulling in more.
Work moves forward only when the next stage has capacity (is under its WIP limit). This pull system is what creates smooth flow instead of pile-ups.
Track how long items take to flow through. Where work consistently piles up is your bottleneck — the visible constraint to attack first.
Use the metrics and the visible bottlenecks to make incremental improvements. Kanban has no sprint boundary forcing change, so the discipline is continuous, evolutionary refinement.
A team was constantly busy — everyone juggling several tasks at once — yet little actually shipped. Work piled up half-finished at the review stage while people kept starting new items to feel productive. Throughput was low despite frantic activity.
Introducing WIP limits felt wrong at first — deliberately capping how much could be in progress seemed like slowing down. But it did the opposite: with a limit, the team couldn't start new work until review cleared, so the review bottleneck became visible and got attention, half-finished work got finished, and throughput rose. Starting less genuinely meant finishing more.
The deliverable is a working board — visualised stages, WIP limits, pull-based flow — with cycle-time tracking to surface bottlenecks.
| Practice | Without it | With it |
|---|---|---|
| Visualise | Work is hidden in heads/tickets | Whole flow is visible |
| Limit WIP | Everything started, little finished | Finishing beats starting |
| Pull | Work pushed, piles up | Smooth, capacity-matched flow |
| Measure flow | Busyness mistaken for output | Cycle time reveals bottlenecks |
Kanban's quiet radicalism is the WIP limit: it raises throughput by restricting work, because a team that starts less finishes more. Busyness and delivery are not the same thing, and Kanban makes the difference visible.
Choosing between Kanban and Scrum is really a question of what your work is like. Scrum's time-boxes optimise for learning — regular cycles of plan, build, inspect, adapt — which suits product development with real uncertainty. Kanban's continuous flow optimises for throughput — which suits work that arrives unpredictably and continuously, like support, operations, or mature delivery. Neither is more ‘advanced’; they answer different needs. And many teams blend them (‘Scrumban’). The deeper lesson Kanban teaches every team, sprint-based or not, is that limiting work in progress is one of the most reliable ways to ship more — a truth that feels wrong until you've watched a WIP limit unstick a clogged board.
A board without WIP limits is just a to-do list. The limits are what create flow.
Busyness isn't throughput. Finishing in-progress work ships; starting new work doesn't.
The board shows where work piles up. Attack that constraint, not the busy-looking stages.
If work is continuous and unpredictable, Kanban fits better than Scrum's time-boxes.
Scrum optimises for learning via time-boxes; Kanban for continuous flow. Tools 04–08 cover Scrum's machinery.
Where Scrum uses velocity (Tool 03), Kanban uses cycle time and throughput.
Part of the spectrum of delivery frameworks (Tools 10, 11) beyond basic Scrum.
The 'finish before starting' discipline applies to the discovery backlog too (Module 3, Tool 24).
Picture a team where everyone is busy but little ships, with work piling up at one stage. What WIP limit would you add, and where, to force finishing over starting?
Predict what happens to throughput — and to the visibility of the bottleneck — once that limit is in place.
If capping work-in-progress to raise output still feels backwards, sit with it — that counterintuitive truth is the single most valuable thing Kanban has to teach.