Kanban Explained: Flow, WIP Limits and Pull Systems

Kanban is a method for managing work as a flow rather than as batches. You visualise the actual process, limit how much can be in progress at once, and manage the system so that work moves smoothly from request to done.

It looks less prescriptive than scrum — no fixed iterations, no required roles — and teams often adopt it expecting an easier ride. In practice it is more demanding, because it has exactly one mechanism that produces the benefit, and that mechanism is the one people quietly remove.

The parts that matter#

Visualise the real workflow. Not an idealised version. If work waits three days for review and another two for a test environment, those are columns. A board that omits the waiting states hides precisely what you need to see, because delay lives in the queues rather than in the work.

Limit work in progress. A maximum number of items per column, or across the board. This is the mechanism. Everything else on this page is supporting detail.

Make policies explicit. What "ready" means, what "done" means for each column, how items are prioritised, what qualifies as expedited. Unwritten policies get applied inconsistently and are argued about weekly.

Manage flow. Watch where work accumulates and fix that, rather than exhorting people to be faster.

Improve continuously. Kanban does not mandate a retrospective; teams that do not schedule one usually stop improving.

Why WIP limits are the whole point#

Starting more work does not finish more work. It creates queues, and every queue adds delay to everything behind it. Multitasking adds switching cost. Half-finished work carries risk, ages, and sometimes has to be redone when priorities move.

A WIP limit makes the queue visible and forces a decision: when the limit is reached, you cannot start anything new. The team's attention moves to whatever is blocking the items already in progress — which is exactly the behaviour you want and exactly the behaviour that feels wrong at first, because someone appears idle.

A team member with nothing to start is not a problem. They should be helping finish something, or the system has a constraint upstream worth fixing. The instinct to hand them a new item is what converts a pull system back into a push system with a nicer board.

🔴 A board with no WIP limits is a to-do list on a wall. It provides visibility, which has some value, and none of the flow benefit. If you adopt one thing from kanban, adopt this.

The metrics#

Cycle time — from starting work to finishing it. The primary measure, and the one to reduce.

Lead time — from request to delivery, including the wait before work began. What the customer experiences, and usually far longer than the team expects.

Throughput — items completed per week. More useful for forecasting than estimates, because it is measured rather than guessed.

Work in progress — how much is open right now. Watch it rise before cycle time follows; these move together with a lag.

Flow efficiency — time actually being worked, divided by total elapsed time. It is frequently under 20% on first measurement, which is uncomfortable and immediately useful: it says the problem is queues, not effort.

Forecast with the distribution of past cycle times rather than a single average. "85% of items finish within nine days" is a statement you can plan against; "average six days" hides the tail that causes every escalation.

Where kanban fits better than sprints#

Interrupt-driven work. Support, operations, incidents. A sprint commitment is broken weekly by events nobody could plan, and the team gets a fortnightly ritual of explaining why.

Varied item sizes. Where work ranges from an hour to three weeks, batching it into equal iterations helps nobody.

Continuous delivery. If you release when something is ready rather than at a cadence, the sprint boundary is a formality.

Teams that need to fix flow first. Kanban can be applied to the existing process without reorganising anything, which makes it a good starting point where a reorganisation is not available.

Scrum fits better where work is plannable toward a goal, where a cadence of stakeholder feedback is valuable, and where a team benefits from the structure while it is learning. Many teams end up with a hybrid — flow-based work with a planning cadence and a retrospective — and that is a reasonable destination if it is chosen rather than drifted into.

Common mistakes#

No WIP limits. Covered above, and by a distance the most common.

Limits set too high. A limit above what the team was already doing changes nothing. Set it slightly uncomfortable and adjust from evidence.

Hidden columns. Waiting states left off the board because they are "not our step". Those steps are where the time goes; excluding them means measuring the small part of the process you control and being puzzled by the lead time.

Everything expedited. An expedite lane used more than rarely means priorities are being set by whoever asks loudest, and the ordinary queue stops moving.

Board not reflecting reality. Items sitting in "in progress" that nobody has touched for two weeks. The board becomes decoration, and the metrics computed from it become fiction.

Measuring individuals. Throughput and cycle time describe the system. Applied to people they produce smaller items, avoided collaboration, and numbers that improve while delivery does not.

A realistic starting point#

Map the workflow as it actually is, including the waiting. Put current work on it. Set a WIP limit per column at roughly the number of people who work in that column. Write down what "done" means for each column. Measure cycle time from the day you start.

Then hold a short weekly look at what is blocked and what is ageing. Two questions do most of the work: what has been sitting the longest, and what is stopping it?

FAQ#

Do we need to abandon sprints to use kanban?#

No. Many teams keep a planning cadence and a retrospective while managing the work as flow. What matters is that WIP is limited and flow is measured — the iteration boundary is optional.

What WIP limit should we start with?#

Roughly the number of people who work in that column, then reduce until it is slightly uncomfortable. If the limit is never reached it is not doing anything. Adjust based on what happens to cycle time, not on how it feels in the first week.

How do we forecast without estimates?#

From throughput and cycle-time distribution. If the team completes eight to twelve items a week and 85% of items finish within nine days, you can forecast a batch of work with a confidence range. This is usually more accurate than estimating, because it is measured from what actually happened.

What about urgent work?#

Define an expedite policy in advance: what qualifies, how many can be in flight (usually one), and what it displaces. The policy matters more than the lane. Undefined urgency expands until everything is urgent.

Does kanban work for non-software teams?#

Yes — it originated in manufacturing and applies well to any knowledge work with a repeatable workflow: legal, HR, marketing, operations. The mechanics are unchanged; the columns differ.

How is this different from a to-do list?#

Limits and policies. Without them you have visibility only, which helps a little. With them you have a pull system that surfaces constraints and reduces delay, which is the actual benefit.

Our board is always full and nothing moves. What now?#

That is the system telling you something, and it is working as intended. Look at where items accumulate — usually a review step, a shared dependency, or a single person everything routes through. Fix that constraint rather than raising the limit; raising the limit hides the signal.

Related Articles#

See Agile for the principles, Scrum for the iteration-based alternative, and Change Management for how new work enters the system.

What else is coming for Kanban