5.2 Kanban Boards: Columns, WIP Limits and Flow

Using a Kanban Board

A Kanban board answers one question a timeline cannot: where is the work stuck right now? Cards move left to right across columns that represent real stages, and the moment work stops flowing, the board shows you exactly where — usually days before anyone would have raised it in a status meeting.

New to this? This page assumes you know what a task and a deliverable are, and it compares against the timeline view. The three project views  ·  Gantt charts  ·  Glossary

In short

  • The board is not the method — the limits are. Columns without a cap on how much may sit in them is just a to-do list drawn sideways.
  • Kanban optimises for finishing, not starting. That is the whole point, and it is why it feels uncomfortable at first.
  • A pile-up is information, not a failure. The column where cards stack is your constraint, and it is rarely the column you assumed.
  • Columns must describe what actually happens — including the waiting. A board that hides the waiting cannot show you the delay.

What a Kanban board is

A board has one column per stage of your real workflow and one card per piece of work. A card enters on the left, moves right as it progresses, and leaves at Done. That much is obvious and most teams get there on their own.

The part that makes it Kanban rather than decoration is the number written at the top of each column: the work in progress limit. It caps how many cards that column may hold at once. When the column is full, nobody may move a new card into it — and the only way to unblock yourself is to help finish something already there.

That single rule changes the team's behaviour more than any process document. Starting new work stops being free.

How to read a board

Below is a board mid-week. Nothing is on fire, nobody has missed a deadline, and there is already a clear problem visible.

A Kanban board with a bottleneck in the Review column Five columns: Backlog with four cards and no limit, To Do with two cards against a limit of three, In Progress with one card against a limit of two, Review with three cards against a limit of two and therefore over its limit, and Done with three cards completed this week. Work is piling up in Review, so the constraint is review capacity rather than development capacity. Backlog no limit To Do 2 / 3 In Progress 1 / 2 Review 3 / 2 — over limit Done this week Export to CSV Bulk edit Audit log Dark mode Search filters Email digest Payment retry Login rate limit Invoice PDF Timezone fix Webhook retries SSO login Error banner Work is piling up here The constraint is review capacity — not developers In Progress looks healthy at 1 / 2 — which is why the pile-up is easy to miss.
The instinct is to look at In Progress, see spare capacity, and start something new. The board is telling you the opposite: three items are waiting on review, and adding a fourth in-progress card makes that queue longer, not shorter. The right move is for a developer to go and review something.

This is the everyday value of a board. It converts “we feel busy but nothing is shipping” into a specific, addressable fact: the constraint is review, and review is where the next hour of effort belongs.

Why WIP limits work

Limiting work in progress feels like slowing down. It does the opposite, for a reason that is not intuitive until you have watched it happen.

Every item a person holds simultaneously carries a switching cost — reloading the context, re-reading the thread, remembering where they got to. Hold five things and a meaningful share of the week is spent on that reloading rather than on the work. Worse, none of the five finishes, so none of them delivers any value at all. Work that is 90% complete is worth exactly nothing to whoever is waiting for it.

A WIP limit forces the team to finish before starting. Throughput goes up not because anyone works harder, but because less effort is lost to context switching and less work sits in a half-done state producing nothing.

Where to set the limit. A common starting point is roughly one to two items per person in the column, then tighten it until the team feels mild discomfort. If nobody ever hits the limit, it is not doing anything. If work is permanently jammed against it, either the limit is too tight or you have found a genuine capacity problem worth escalating — and either way, you now know.

Designing the columns

Most board problems are column problems. Three rules:

  • Columns must describe what actually happens, including the waiting. If work regularly sits waiting for a client sign-off, “Waiting on client” is a column. Hide it inside “In Progress” and your board will tell you the team is busy when it is actually blocked.
  • Split doing from done-and-waiting. A single “Review” column conflates “someone is reviewing this” with “this is queued for review”. Teams that split them usually discover the queue is the problem, not the reviewing.
  • Do not make “Blocked” a column. Blocked is not a stage of work, it is a condition. Make it a flag on the card so the card keeps its place in the flow and you can see how long it has been stuck.

What a board measures

Because every card carries timestamps as it moves, a board gives you two numbers that are more honest than a percentage-complete figure:

  • Cycle time — how long a card takes from start to done. This is what you quote when someone asks “how long will this take?”, and it is based on evidence rather than optimism.
  • Throughput — how many cards finish per week. Track it for a few weeks and you can forecast without estimating anything at all.

Both beat a status percentage for the same reason: they count things that actually finished.

Kanban or Scrum?

They are frequently presented as rivals; in practice most teams end up somewhere between them.

KanbanScrum
CadenceContinuous flow — work enters when there is roomFixed sprints of one to four weeks
CommitmentPer itemA sprint's worth, agreed up front
Handles interruptionWell — reprioritise the queue at any timePoorly — interruptions break the sprint commitment
Best forSupport, operations, mixed or unpredictable demandFeature delivery with a stable team and plannable work
Core measureCycle time and throughputVelocity per sprint

A reasonable rule: if your week is regularly interrupted by work you could not have planned, a board fits better than a sprint. If your work arrives in plannable batches and the team benefits from a rhythm, sprints give you a useful heartbeat.

Common mistakes

A board with no limits

Every column unbounded means the board records what is happening but changes nothing. This is the single most common version of “we tried Kanban and it didn't help”.

The board as status theatre

Cards updated the morning of the weekly meeting, for the manager's benefit. The board is a coordination tool for the team doing the work; the moment it becomes a report, it starts lying.

Cards with no age

If nothing shows how long a card has sat where it is, items quietly rot in a middle column for a month and the board still looks fine.


Who lives in this view

Every project view answers a different person's question. The board is the home screen for the people doing the work.

RoleWhat the board tells them
Team members (home view)What to pick up next, what is theirs, and when to stop starting and go help finish something
Team lead (home view)Where the flow is jammed today, and which constraint is worth an intervention
Project managerWhether execution is healthy — but not whether the date will hold. That is the timeline's job
Sponsor / stakeholderLittle, directly. Card-level detail is noise at their altitude; give them milestones instead

If your engineers are being asked to read a timeline daily, or your sponsor is being sent a screenshot of the board, someone is looking at the wrong view for the question they are being asked.

How this looks in AB

AB Project Management ships a Kanban board alongside the Backlog and Gantt views, over the same underlying tasks — so moving a card is not a separate bookkeeping step, it is the status change. Columns follow the project's configured statuses, which means the board reflects the workflow your team actually agreed rather than a generic three-column default. Because assignments, comments and subtask progress live on the same records, a card carries its full history with it, and work driven by an AI assistant over the MCP server appears on the board exactly like anything else.


Terms used on this page

Every term below is defined at more length in the full project management glossary.

Kanban
A flow-based method where work moves across a board of columns, each with a limit on how many items it may hold at once. More →
WIP limit
A cap on how many items may sit in a given column at once. The mechanism that forces finishing before starting — without it, a board is only a picture. More →
Cycle time
How long one item takes from the moment work starts to the moment it is done. Measured from the board rather than estimated.
Throughput
How many items the team completes per period. Combined with cycle time it forecasts delivery without requiring an estimate per item.
Blocker
Anything stopping work that the card's owner cannot resolve alone. A flag on the card, never a column. More →
Backlog
The ordered list of everything the team could work on, most important first. The board's left-hand column is where it meets the flow. More →
Scrum
An Agile framework built on fixed-length sprints with defined roles, events and artefacts. Boards are common inside Scrum, but the sprint commitment is what distinguishes it. More →
Velocity
Work completed per sprint, used for forecasting in Scrum. Kanban teams generally use throughput instead, since there is no sprint boundary to count against. More →
Definition of Done
The checklist every card must satisfy before it may enter the Done column. Without one, “done” means whatever the person moving the card decides. More →

Related reading

The same work, by date

When the question is “will we make it?” rather than “where is it stuck?”, you need the timeline.

5.1 Using Gantt Charts →

Where the cards come from

The backlog decides what enters the board next, and in what order.

5.3 Managing a Backlog →

Measuring real progress

Why a card reaching Done is not the same as a deliverable being acceptable.

6.1 Monitoring Deliverables →

Published on: 2026-07-26 Last updated on: 2026-07-26

Questions & answers

Have a question about this topic? Ask below — no sign-up needed. The team reviews and answers questions here.

No questions yet — be the first to ask.

Ask a question

We’ll send a one-time email to confirm your address. Questions appear after a quick review.