Kanban and flow

Why it matters

Not all work fits neatly into two-week sprints. A support team handles requests as they arrive. An operations team mixes planned work with urgent fixes. A design team serves several product teams at once. Kanban gives these teams, and many Scrum teams too, a way to see their work, stop starting too many things at once and finish work faster and more predictably.

Where it comes from

Kanban is Japanese for "signboard" or "visual card". The idea comes from the Toyota Production System in the mid-20th century, where cards signalled when to produce more parts, so nothing was made before it was needed. In the 2000s David J. Anderson and others adapted it for knowledge work. Today the core practices are described in free guides such as The Kanban Guide and Scrum.org's Kanban Guide for Scrum Teams, and in the Kanban Method taught by Kanban University.

The core practices

The wording differs between guides, but the core practices are commonly summarised as:

1. Visualise the work. Put every item on a board with one column per stage of your workflow.
2. Limit work in progress (WIP). Set a maximum number of items allowed in each active column.
3. Manage flow. Watch how items move, find where they get stuck and fix the cause.
4. Make policies explicit. Write down the rules: what "done" means for each column, who can pull work, how urgent items are handled.
5. Improve continuously using feedback and data.

Kanban has no required roles, no sprints and no fixed events. You start with what you do now and improve it in small steps.

A board with WIP limits

Northside Sports Centre's app team uses this board:

| Backlog | Ready (5) | In progress (3) | Review (2) | Testing (2) | Done |
|---------|-----------|-----------------|------------|-------------|------|
| ...     | A  B  C   | D  E  F         | G  H       | I           | J  K |
|         | L         |                 |            |             |      |

The numbers in brackets are WIP limits. "In progress" already holds three items, so nobody may start a fourth. If a developer finishes item D, they pull the next item from Ready. Work is pulled when there is capacity, not pushed onto people.

Why limiting WIP works

It feels backwards: surely starting more things gets more done? It does not, for three reasons.

• Context switching: every switch between tasks costs time to get back into the problem.
• Queues hide: with ten things "in progress", most of them are actually waiting.
• Little's Law: for a stable system, average cycle time = average WIP / average throughput.

A worked example. The team finishes about 6 items a week (throughput). If they keep 18 items in progress, the average item takes 18 / 6 = 3 weeks from start to finish. If they cut WIP to 6 items, with the same throughput, the average item takes 6 / 6 = 1 week. Nobody worked faster. Items simply waited less.

What a WIP limit makes you do

When a column hits its limit, the board is telling you something. Suppose Review (limit 2) is full because the only reviewer is on leave. Developers cannot start new work, so instead they swarm: help review, pair on testing, or fix whatever blocks the flow. This is the point. WIP limits turn a hidden bottleneck into a visible one and push the team to fix it.

Setting the first limits

There is no perfect formula. A common starting point:

• Count how many people work in each stage and start with a limit near that number (or slightly less, to encourage pairing).
• Run for two or three weeks and watch: if items queue up before a column, look at that stage; if people are often idle, raise the limit a little.
• Change one limit at a time so you can see the effect.

Kanban and Scrum together

Many teams use a Kanban board inside Scrum (sometimes called "Scrumban"): sprints, planning and retrospectives from Scrum, plus WIP limits and flow metrics from Kanban. Scrum.org's Kanban Guide for Scrum Teams describes exactly this.

Common mistakes

• A board without WIP limits: that is a task board, not Kanban.
• Ignoring the limits "just this once" until they mean nothing.
• Too many columns, so the board copies an org chart instead of the workflow.
• No explicit policies, so everyone has a different idea of when an item can move.

Quick recap

• Kanban visualises work, limits WIP, manages flow, makes policies explicit and improves continuously.
• Work is pulled when there is capacity, not pushed.
• Lower WIP shortens cycle time without anyone working faster (Little's Law).
• Kanban can stand alone or run inside Scrum.

Try it

Open the Do tab and build a Kanban board with WIP limits for your own work.