Kanban: Visualize Flow, Limit Work in Progress

Scrum gave the team a rhythm: fixed sprints, a planning meeting, a review at the end. That rhythm suits work that arrives in predictable batches. But some teams don’t get to choose when work shows up. A support desk, a hospital ward, a maintenance crew, an operations team — for them, work arrives whenever it arrives, and the calendar can’t decide the pace. Kanban is built for exactly that world.

Kanban is deceptively simple. It has two ideas at its heart: make the work visible, and limit how much is in flight at once. That’s most of it. This page will show you why those two small moves — a board on the wall and a number written above a column — quietly fix problems that no amount of encouragement or hard work ever could. And it will explain the counterintuitive truth underneath: that the way to finish more is almost always to start less.

Make the work visible

Most work is invisible. It lives in people’s heads, in inboxes, in half-finished tasks nobody else can see. When you ask a team “how are we doing?”, you get a vague answer, because nobody actually holds the whole picture. Work hides, and hidden work can’t be managed.

A Kanban board drags every piece of work into the open. At its simplest it’s three columns:

┌──────────────┬──────────────┬──────────────┐
│   TO DO      │    DOING     │    DONE       │
├──────────────┼──────────────┼──────────────┤
│  ▢ Fix leak  │  ▢ Onboard   │  ▢ Restock    │
│  ▢ Reply to  │    new hire  │    shelf 3    │
│    supplier  │  ▢ Q3 report │  ▢ Patch      │
│  ▢ Order     │              │    server     │
│    stock     │              │               │
└──────────────┴──────────────┴──────────────┘

Each card is one piece of work. As work progresses, its card moves left to right. In ten seconds, anyone — a team member, a manager, a person from another department — can see the true state of things: what’s waiting, what’s being worked on right now, what’s finished. Nobody has to ask. Nobody has to remember.

This sounds almost too basic to matter, but the effect is large. A board is a shared, honest source of truth. It ends the awkward conversation where someone thinks a task is done and someone else thinks it hasn’t started. It exposes the work that’s been sitting untouched for two weeks. And it does all this without a single meeting.

In practice — the board that made the queue honest

A small print shop kept promising customers their orders “by Friday,” then missing it. The owner put a whiteboard on the wall with three columns and a card for every open order. Within a week the problem was obvious to everyone: there were nineteen cards in DOING and only two people. Work wasn’t slow because anyone was lazy — it was slow because everything had been started and almost nothing had been finished. The board didn’t fix the problem by itself. But it made the problem impossible to ignore, which is the necessary first step.

Limit work in progress

Here is where Kanban stops being just a nice display board and becomes a method. You write a number above a column — a cap on how many cards may sit in it at once. This is called a WIP limit, short for work-in-progress limit.

┌──────────────┬──────────────────┬──────────────┐
│   TO DO      │   DOING (max 3)  │    DONE       │
├──────────────┼──────────────────┼──────────────┤
│  ▢ Fix leak  │  ▢ Onboard hire  │  ▢ Restock    │
│  ▢ Reply     │  ▢ Q3 report     │  ▢ Patch      │
│  ▢ Order     │  ▢ Invoice run   │    server     │
│    stock     │  ── FULL ──      │               │
└──────────────┴──────────────────┴──────────────┘

“DOING (max 3)” means: no fourth thing may enter DOING until one of the current three leaves. If DOING is full and you have spare capacity, you are not allowed to start something new. Instead, you help finish something that’s already in flight.

At first this feels wrong. It looks like a rule that stops people working. Surely a busy team should start whatever it can? But the WIP limit is the whole point, and understanding why is understanding Kanban.

The counterintuitive core: start less to finish more

Imagine a single lane at a supermarket checkout. If the cashier serves one customer fully, then the next, then the next, the line moves. Now imagine the cashier scanning one item from each of five customers in turn, rotating between them forever. Nobody’s basket ever empties. Everyone waits longer. No groceries leave the store. The cashier is working flat out the entire time — and getting worse results.

That’s a team with too much work in progress. Every started-but-unfinished task carries hidden costs:

• Switching between tasks is expensive. Each time you drop one thing and pick up another, you pay a tax: you forget where you were, you re-read, you re-orient. Studies of task-switching generally find this cost is real and larger than people expect. Five half-done tasks aren’t five times the progress of one — they’re often less.
• Nothing ships until it’s done. A task that’s 90% finished delivers zero value. Value arrives only when work crosses into DONE. Ten things at 90% help no one; three things at 100% help three people.
• Unfinished work hides problems. A blocked task sitting in DOING looks like progress but isn’t. The more of them there are, the harder it is to see which one is actually stuck.

So the WIP limit does something clever. By capping how much can be started, it forces the team to finish. When you can’t start a fourth thing, the natural move is to swarm on getting one of the three across the line. Work stops piling up in the middle and starts flowing out the end. The team feels less busy and delivers more. That is the counterintuitive core of Kanban: starting less finishes more.

The common trap — treating “everyone is busy” as the goal

The instinct of most managers is to maximize how busy people are — idle time looks like waste. So they keep assigning work, and everyone always has ten things going. But a team where everyone is 100% busy is a team where every task waits behind other tasks, and nothing moves quickly. Full utilization and fast delivery are enemies, not friends. A little slack is what lets work flow. If your team is drowning and shipping nothing, the fix is usually to start fewer things at once — not to push harder.

Continuous flow, not fixed sprints

Scrum works in batches: you plan a sprint, commit to a set of work, and check in at the end of the fixed window. Kanban has no sprints and no fixed window. Work flows continuously.

The rhythm is pull, not push. Instead of a plan handing work to people on a schedule, each person pulls the next item from TO DO the moment they have capacity — the moment a slot in DOING opens up. There’s no big planning event and no artificial deadline every two weeks. When something is finished, the next thing begins. Priorities can change at any time simply by reordering the TO DO column; whatever sits at the top gets pulled next.

   TO DO            DOING            DONE
  (ordered)        (capped)
      │                │               │
      └── pull when ───┘               │
          a slot opens                 │
                       └── finish, then ┘
                           pull again

This is why Kanban fits work that can’t wait for a sprint boundary: a support ticket that lands at 3pm, an urgent repair, a customer request. You don’t tell them “we’ll consider that in our next planning meeting.” You place the card at the right spot in the queue, and it gets pulled when capacity frees up. The method bends around the work, not the other way round.

The evidence — flow and finishing

The thinking behind WIP limits comes from decades of study in manufacturing and operations, where a well-established relationship (often called Little’s Law) links how long work takes to how much of it is in the system at once: the more items in progress, the longer each one takes to get through. The practical takeaway is robust and repeated across industries — reducing the amount of work in flight tends to shorten how long each item takes to finish. Kanban simply applies that operations insight to knowledge work and services.

Bottlenecks become obvious — and shared

The most quietly powerful thing a Kanban board does is make bottlenecks visible. A bottleneck is the slowest step — the place where work piles up because it can’t get through fast enough.

On a board, a bottleneck announces itself: cards stack up in front of one column and starve the columns after it. You don’t have to guess where the problem is. You can see it.

   TO DO      DESIGN     REVIEW (max 2)   BUILD      DONE
   ▢▢▢         ▢          ▢ ▢ ▢ ▢ ▢         (empty)    ▢
   ▢▢                     ── piling up ──
              ↑ work flows in fast    ↑ everything jams here

Here, REVIEW is the bottleneck: work floods in but can only trickle out, so it dams up and everything downstream sits idle. This changes the whole conversation. Without the board, when things are late, people look for someone to blame — “the reviewers are slow,” “the builders are always waiting around.” With the board, the constraint is a visible fact on the wall, not an accusation. The question becomes: how do we, together, help work get through the review step? Maybe someone else learns to review. Maybe the review step is simplified. Maybe the whole team pauses starting new work and clears the jam.

That shift — from finger-pointing to a shared problem the team can see and solve — is one of Kanban’s deepest gifts. The board turns “whose fault is this?” into “what does the flow need?”

Case study — Toyota’s andon cord (from the 1950s onward)

On Toyota’s assembly lines, any worker who spots a problem can pull a cord — the andon cord — that signals trouble and can stop the line. It sounds reckless to let one person halt production, but the logic is pure flow: a defect that keeps moving downstream becomes far more expensive to fix later, and a hidden problem is worse than a visible one that everybody rallies to solve. The cord made problems visible and shared the instant they appeared. Kanban (whose name and lineage trace back to Toyota) carries the same spirit: surface the constraint immediately, and treat it as everyone’s problem to fix, not one person’s fault to hide.

When Kanban fits

Kanban shines when work arrives unpredictably and continuously, when priorities shift often, and when you want a low-ceremony way to improve — no big process to install, just a board and a limit you tighten over time. It’s gentle to adopt: you can lay a Kanban board over how a team already works, without reorganizing anything, and start learning from what you see.

It fits less well when work genuinely benefits from a committed, protected window — when a team needs to say “for the next two weeks, this is the plan, leave us alone to deliver it.” That’s Scrum’s strength. Many teams blend the two. Which method fits which situation — and how to adapt either one to your reality — is the subject of the next page.

How it connects

Kanban is one of the two workhorse methods introduced in this part, sitting alongside Scrum. Both are practical answers to the question the part overview posed: how do you turn effort into outcomes reliably? Where Scrum leans toward plan-then-build in short bursts, Kanban is continuous adaptation — pull the next thing, watch the flow, fix the constraint. The closing page helps you choose and combine them.

Try this

This week, make your team’s work visible and cap it. Draw three columns — To Do, Doing, Done — on a whiteboard or a shared document, and write a card for every piece of open work. Then, above Doing, write a WIP limit: try a number equal to the number of people, or even one below it. For one week, hold the rule that nothing new enters Doing until something leaves. Notice what happens to how quickly things actually finish — and to how it feels.

Reflect

1. If you drew your team’s real work on a board right now, how many cards would be sitting in “Doing”? Is that more than the number of people?
2. Think of a task that’s been “almost done” for a while. What is it costing you to have it 90% finished instead of shipped?
3. Where do you feel the pull to “just start one more thing”? What usually happens to the things already in progress when you do?
4. If work is piling up somewhere in your process, where is the bottleneck — and do people currently treat it as a shared problem or someone’s fault?
5. Does your work arrive in predictable batches, or continuously and unpredictably? What does that suggest about whether Kanban or a fixed rhythm fits you better?

Show reflections

1. Most teams are shocked by the count — Doing is almost always overloaded. If the number of in-progress items comfortably exceeds the number of people, that alone explains why things feel slow, and it points straight to a WIP limit as the fix.
2. The aim is to feel, concretely, that partly-done work delivers nothing. The cost is real: the customer still waits, the value still hasn’t landed, and the unfinished task quietly occupies mental space. Naming that cost is what makes “finish before you start” more than a slogan.
3. Watch for the honest answer: starting more usually stalls what’s already going, because attention and effort get split. The pull to start is often about looking busy or feeling productive, not about finishing faster.
4. A good answer locates the slowest step and notices the tone around it. If the reflex is blame, that’s a sign the constraint is invisible; making it visible on a board is what converts blame into a joint problem the team can attack together.
5. Predictable, plannable batches lean toward a fixed rhythm like Scrum; unpredictable, continuous arrival leans toward Kanban’s pull-and-flow. Many real situations are a mix — which is exactly why the next page is about choosing and blending rather than picking a side.