Kanban: Flow, WIP Limits, and Pull

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. Let's look at how this works and why limiting work, oddly enough, speeds up delivery.

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. The board must honestly show how work actually moves, otherwise it won't help you spot problems.

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 one column is a signal that something is slowing things down there: not enough people, tasks that are too large, or the 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 three 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." If throughput (how many tasks the team completes per week) is fixed, then by reducing the number of concurrent tasks you reduce their lead time.

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.

A simple example. Five tasks, two days of work each:

In total the work takes the same 10 days, but in the second case the first value is delivered as early as day 2, not day 10. A WIP limit 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.
• Performance problems become visible immediately: if the column before the bottleneck is overflowing, it's obvious to everyone where to fix the process.

Pull turns WIP limits from a formal rule into a living mechanism of flow self-regulation.

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 task was taken into work (or even put into the queue) to the moment it's "Done." This is what the customer feels: how long they wait for a result after a request. 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. This is the rate at which finished results come out. 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 and bottom boundaries — this is lead time and throughput made visible.

These metrics are more honest than velocity because they describe the delivery of value, 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 neatly into iterations (sprints) with planning, a goal for 1-2 weeks, and a fixed set of tasks. This suits product development, where the team agrees on a sprint goal and protects it 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.
• Streaming work with similar but constantly incoming tasks.
• Teams where it's important to pick up something urgent at any moment without breaking a sprint.

In short: a steady flow of tasks and support — Kanban; product iterations with a sprint goal — Scrum.

There is also a hybrid — ScrumBan. It takes the rhythm and ceremonies from Scrum (for example, a regular planning meeting) 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 task.
• Multitasking is harmful: sequential execution 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.

What to read next

• Scrum — an iterative framework with roles, sprints, and ceremonies.
• Development models — an overview of approaches to organizing work on a product.