← back to the section

A team sets up a board, spreads tasks across columns, and decides it now has Kanban. In reality, Kanban starts not with a board but with two ideas: make the flow of work visible and limit the number of things the team drags along at once. Without that, the board is just a list of tasks in three columns.

Kanban is a way to manage the flow of work. It does not split time into iterations and does not require roles like a Scrum Master. It says: watch how tasks flow from "to do" to "done," find the places where they get stuck, and don't overload the system.

no limit — all five started at once Queue In progress Done WIP limit — one card in progress Queue In progress Done day 2 task 1task 2task 3task 4task 5 task 3task 4task 5 task 2 task 1 dashed — five tasks share one team: each takes five times longer day 4 task 1task 2task 3task 4task 5 task 4task 5 task 3 task 1task 2 dashed — five tasks share one team: each takes five times longer day 6 task 1task 2task 3task 4task 5 task 5 task 4 task 1task 2task 3 dashed — five tasks share one team: each takes five times longer day 10 task 1task 2task 3task 4task 5 task 1task 2task 3task 4task 5 both boards finished in ten days — the difference is when the first value arrived

The same team gets one task to "Done" every two days. On top all five are started at once: every bar creeps forward and nothing is done until day ten. Below, the limit keeps one card in progress and the rest wait in the queue — so the customer gets a result on day two, day four, day six. The same amount of work, the same ten days; the difference is when the first value arrived.

The board as a map of the flow

The main tool in Kanban is a board with columns. Each column is a stage a task passes through: for example, Backlog → Analysis → Development → Testing → Done. A task (a card) moves left to right, and at any moment you can see where it is and what's happening to it.

An important difference from a plain to-do list: columns in Kanban describe the real stages of your process, not abstract "to do / doing / done." If you have a code review between development and testing, add a separate column. Otherwise the board won't show where work actually stalls.

What visualization gives you:

  • You can see at which stage tasks pile up — that is the bottleneck of the flow.
  • You can see who is working on what and whether any stage is overloaded.
  • You can see "stuck" cards that haven't moved in a long time.

The board is not decoration but a diagnostic instrument: a pile-up of cards in a column says something is slowing down there — not enough people, tasks that are too large, or a next stage that can't keep up in pulling them.

WIP limits: why less means faster

WIP (Work In Progress) is the number of tasks that are being worked on at the same time. The core mechanic of Kanban is to set limits on WIP: for example, "no more than two cards in the Development column at once."

At first glance this sounds counterintuitive: wouldn't a limit slow the team down? Quite the opposite. Little's Law — a simple relationship from queueing theory — explains it:

Average lead time = Average number of tasks in progress / Throughput

In plain terms: the more tasks you keep in progress at once, the longer, on average, each of them takes to reach "Done." A team's throughput is what it is and does not change quickly, while the number of concurrent tasks is exactly what the limit controls. Let's put numbers in — the team gets eight tasks per week to "Done":

live example

throughput = 8  # tasks per week the team gets to "Done"
for wip in (24, 16, 8):
    print(f"{wip:2} in progress -> each task takes {wip / throughput:.1f} weeks")
Run

Running examples is part of paid access. There the same code runs inside the article: editor, run and check next to the paragraph. Three free days →

Three times less work in progress means three times shorter waiting — with the same team and the same speed.

The second enemy is multitasking. When a person is juggling five tasks at once, they constantly switch between them, and each switch costs time to "remember where I left off." As a result, five tasks started at the same time all finish late. But if you do them one at a time, the first is done quickly, the second a bit later, and so on. The customer receives value sooner.

That is what the animation above shows. Five tasks, two days of work each: take all five at once and nothing is done until day 10; do them one at a time and the first reaches the customer on day 2, the second on day 4, and so on. In total the same 10 days, but value started flowing five times sooner. A WIP limit is what forces the team to finish what it started before grabbing something new.

Pull instead of push

Kanban works on the principle of pull, not push. The difference is who initiates a task's movement.

With push, work is handed down from above or from the previous stage regardless of whether the next stage is ready to accept it. An analyst finishes a specification and "tosses" it to the developers, even if they are up to their necks in work. Tasks accumulate in front of overloaded stages, and queues form.

With pull, a stage takes the next task itself — but only when it has freed up a slot under the WIP limit. A developer finishes a card, a free slot opens up, and they go and take the next one from the previous column. Work is not forced forward but pulled as capacity becomes available.

What this changes:

  • The pace is set by the bottleneck, not by a manager or an optimistic plan.
  • Tasks don't pile up in front of overloaded stages — there's nowhere for them to go, the limit doesn't let them.
  • Problems become visible immediately: an overflowing column before the bottleneck shows everyone where to fix the process.

Flow metrics

Kanban measures not "how many story points we burned this sprint" but how the work flows. There are three basic metrics.

Lead time — the time from the moment a request appears, that is from the card entering the queue, to the moment it's "Done." This is what the customer feels: how long they wait for a result after asking. The time spent in work — counted from the moment the card was taken into "Development" — is measured separately; mixing the two is a mistake, because the wait in the queue drops out of the report and it comes out prettier than reality. The smaller and more stable the lead time, the more predictable the team.

Throughput — how many tasks the team completes over a period, for example per week. Stable throughput lets you forecast: if the team does 8 tasks per week on average, then 24 tasks in the queue is about three weeks.

Cumulative Flow Diagram (CFD) — a cumulative diagram of the flow. Time runs along the horizontal axis, the number of tasks along the vertical, and colored bands show how many cards are in each column on each day. From a CFD you can immediately see:

  • A widening band for some stage — the queue is growing there, a bottleneck.
  • The vertical width of the "in progress" band — this is the current WIP.
  • The slope of the top boundary is how fast work arrives, the bottom one is throughput; the horizontal gap between them is the lead time.

These metrics are more honest than velocity: they describe delivery, not an internal estimate of the amount of work — what matters to the customer is not how many "points" you planned but how quickly and steadily tasks reach completion.

Scrum and Kanban: which and when

Kanban is often contrasted with Scrum, but they are tools for different situations, not rivals.

Scrum is good when work slices into iterations (sprints) with a goal for 1-2 weeks and a fixed set of tasks, and the team protects that goal from interruptions. The role structure (Product Owner, Scrum Master), the ceremonies, and estimation in story points give it rhythm and predictability.

Kanban fits better when the flow of tasks is continuous and priorities change on the fly:

  • Support and operations: requests arrive at an unpredictable pace, and planning in two-week iterations is pointless.
  • Teams where it's important to pick up something urgent at any moment without breaking a sprint.

There is also a hybrid — ScrumBan. It takes the rhythm and ceremonies from Scrum but adds a board with WIP limits and pull from Kanban, often dropping the rigid sprint boundaries. It's a sensible choice for teams that started with Scrum but ran into a constant stream of urgent tasks breaking their iterations.

In short

  • Kanban is flow management: make the movement of tasks visible and don't overload the system.
  • A board with stage columns is a diagnostic instrument: a pile-up of cards reveals a bottleneck.
  • WIP limits cap the number of concurrent tasks: by Little's Law this shortens the lead time of each, and sequential work delivers the first value sooner than parallel work.
  • Pull — a stage takes a task itself when a slot frees up; the pace is set by the bottleneck, not by a plan.
  • Flow metrics: lead time (time to completion), throughput (tasks per period), cumulative flow (a diagram of queues).
  • A steady flow and support — Kanban; product iterations — Scrum; the hybrid — ScrumBan.
  • Scrum — an iterative framework with roles, sprints, and ceremonies: what Kanban is most often compared with.
  • Estimation and planning — story points and velocity: how an estimate differs from a measurement of flow.
  • Development models — an overview of approaches to organizing work on a product.
  • Extreme Programming — the engineering practices without which frequent delivery is unsafe.