Anatomy of a Kanban Board

A Kanban board is often treated as a simple grid: columns for stages, cards for work items. But effective boards have more structure than that.

The key components:

1. Columns — Stages that work passes through
2. Cards — Individual work items
3. WIP limits — Maximum items allowed per stage
4. Swimlanes — Horizontal divisions for categorizing work
5. Policies — Rules about how work moves (often written on the board)
6. Blockers — Visual indicators for stuck work
7. Queues vs. active stages — Distinguishing waiting from working

Let's explore each of these in depth.

The first rule: columns should reflect how work actually moves, not how you wish it moved.

Common mistakes:

• Using generic stages (To Do, Doing, Done) that hide complexity
• Mapping an idealized process that nobody follows
• Copying another team's board without understanding your context

The right approach:

1. Gather the team (everyone who touches the work)
2. Walk through recent work items: "What happened to this after it was created?"
3. Write down every stage, including waiting states
4. Include the painful truth—if work sits in review for days, that's a stage

Example evolution:

• Before: To Do → In Progress → Done
• After: Backlog → Ready → Dev (WIP: 3) → Code Review (WIP: 2) → QA → Ready for Deploy → Deployed

The expanded board reveals where work actually spends time. You might discover code review takes longer than development.

Not all stages are the same. Some represent active work (someone is doing something). Others represent queues (work is waiting).

This distinction matters because:

• Wait time often dominates lead time
• Queues are where work dies
• You manage queues and active stages differently

Visualizing the difference:

Many teams split columns into two: a "waiting" area and a "doing" area.

| Ready | Development  | Ready for | Code Review | Ready for | Done |
|       | In Progress  | Review    | In Progress | Deploy    |      |

Or use dots/indicators on cards to show "actively working" vs. "waiting."

The insight: If your "In Progress" column is full of work nobody's actually touching, you have hidden queues. Make them visible.

Each column needs a clear Definition of Done (DoD): what must be true for work to leave this stage?

Without clear criteria:

• Work moves prematurely ("it's mostly done")
• Quality varies ("done" means different things to different people)
• Problems surface late ("I thought someone else would do that")

Example DoD for "Development":

• All acceptance criteria met
• Unit tests written and passing
• Code compiles without warnings
• Self-reviewed (no obvious issues)
• Commit message follows convention

Example DoD for "Code Review":

• Two approvals received
• All review comments addressed
• CI pipeline passes
• No merge conflicts

Write these on the board or link to them. They're not bureaucracy—they're shared understanding.