The Complete Guide to Kanban

This is why so many teams report that Kanban "didn't change anything". They adopted a board and stopped. A board without WIP limits shows work but changes no behaviour.

This guide covers what Kanban requires, how to set up a system, how to manage flow, and which metrics tell you whether it is working.

Quick answer: Kanban is a method built on six practices: visualise the work, limit work in progress, manage flow, make policies explicit, implement feedback loops, and improve collaboratively. The board everyone associates with Kanban is only the first of those — the practice that produces the results is limiting work in progress, and it is the one most commonly skipped.

What Kanban Actually Requires

Kanban is a set of practices applied to your existing process, not a new process — it starts with what you do now and improves it incrementally.

The six core practices

Visualise the work. Limit work in progress. Manage flow. Make process policies explicit.

Implement feedback loops. Improve collaboratively and evolve experimentally.

The order matters. Visualisation without limits produces information without change. Limits without explicit policies produce arguments about whether an item really counts.

Why the board is the least important part

The board is the visible artefact, which is why it dominates discussion. Its function is to make the system observable — but observation alone changes nothing.

The behavioural change comes from the WIP limit, because it forces a conversation the team would otherwise avoid: we cannot start this yet. That constraint is what surfaces the bottleneck and shortens cycle time.

Where it came from

Kanban originates in Toyota's manufacturing system, where cards signalled that downstream capacity was available for more work.

The transfer to knowledge work keeps the central idea — capacity signals demand rather than demand overwhelming capacity — and drops the physical mechanism. Understanding the origin explains why pull, not push, is the defining concept.

Kanban Compared to Scrum

Kanban Scrum Cadence Continuous Fixed-length sprints Commitment Per item, as capacity allows Per sprint

Roles None prescribed Product owner, scrum master, team Change mid-cycle Expected and fine Discouraged within the sprint Estimation Optional Usually story points

Throughput and forecasting

Key constraint WIP limits Sprint scope Best for Interrupt-driven work Predictable work needing rhythm Board reset Never Each sprint

Setting Up a Kanban System

Start by mapping how work actually moves including the waiting states, set WIP limits immediately, and write down what must be true for an item to leave each column.

Map the real workflow, including waiting

Trace several recent items end to end and write down every state they occupied — including "waiting on client", "blocked on approval" and "sitting in someone's inbox".

Those waiting states are where most elapsed time goes. Leaving them off the board makes it look tidy and hides your largest problem. Kanban is explicitly designed to start from your current process, so mapping reality rather than an ideal is not a compromise — it is the method.

Set WIP limits from day one

Retrofitting limits to a board already holding forty items feels punitive. Setting them at the start feels like a rule.

A common starting point is one to two items per person in a column, adjusted from observation.

The exact number matters less than having one, because its purpose is to force a conversation when breached.

Tools differ in whether they enforce this. A board that supports per-column WIP limits and swimlanes — Taskzin's board view does — makes the constraint visible rather than aspirational.

Define what done means per column

For each column, write one line stating what must be true for an item to leave it.

Without this, items move when someone feels like moving them, and the board stops reflecting reality within a fortnight. This is the "make policies explicit" practice, and it is the cheapest of the six to implement.

Managing Flow

Work is pulled when capacity allows rather than pushed on a schedule, bottlenecks are attacked rather than worked around, and blocked items are made visible with owners.

Pull, don't push

Nobody starts new work because they are free. They start it because a downstream column has capacity.

This inversion is what prevents the common pattern where work accumulates in front of a constrained stage while everyone upstream stays busy producing more of it.

Find and attack the bottleneck

The column that is permanently full is your constraint. Everything upstream can go faster and delivery will not improve.

Attacking it means adding capacity to that stage, reducing the work arriving at it, or changing the process so less work needs it. Optimising anything else is wasted effort — a point Kanban inherits from lean thinking and one teams repeatedly relearn.

Handle blocked work explicitly

Decide whether blocked items are flagged in place or moved to a blocked column, who owns unblocking them, and how long before escalation.

Blocked work with no owner and no time limit is where cycle time quietly disappears. Making it visible is often enough on its own to shorten it.

The Metrics That Make Kanban Work

Cycle time, throughput and the cumulative flow diagram are the three measures that turn a board into a system you can improve.

Cycle time and its distribution

Cycle time measures elapsed time from work starting to being done. It is what a customer experiences.

Look at the distribution rather than the average. If most items finish in three days and a few take three weeks, the long tail is where your process breaks — and those specific cases repay individual investigation far more than the average does.

Throughput and forecasting Throughput counts items completed per period. With reasonably consistent item sizes it forecasts as well as story points, without estimation.

After eight to ten weeks of history you can forecast delivery ranges from data. "We complete six to nine items a week, so thirty items takes four to five weeks" is a defensible forecast produced without a single estimation meeting.

Cumulative flow and flow efficiency

A cumulative flow diagram shows how much work sits in each state over time, making accumulation visible before anyone complains.

Flow efficiency compares active working time against total elapsed time. For most teams the honest answer is uncomfortably low — often well under half — and the gap is waiting. That figure reframes improvement conversations away from working faster and toward waiting less.

Common Kanban Mistakes

The three failures that neutralise Kanban are running a board with no WIP limits, adding too many columns, and ignoring how long items have been sitting.

A board with no WIP limits

The single most common error. The team gets visualisation, which is pleasant, and no behavioural constraint, which is where the results come from.

If you adopt one practice, adopt this one.

Too many columns

Fifteen columns modelling every conceivable state produce horizontal scrolling and a board nobody reads. Five to seven, including explicit waiting states, suits most teams.

Ignoring the ageing of items

An item sitting in the same column for three weeks is a problem, and boards do not draw attention to it unless you look.

Review item age weekly — anything older than roughly twice your typical cycle time deserves a direct conversation. Ageing is the earliest reliable signal that something has stalled, and it appears well before the deadline is missed.