Kanban Board Patterns

The Board as a Model

A kanban board is, at its best, a visible model of how work actually flows through a team. At its worst, it's a glorified to-do list with three columns and no rules. The difference between the two depends almost entirely on the board's design: which columns exist, what policies govern them, what the rules say about WIP, and what a card's movement actually means.¹

David Anderson's foundational Kanban book in 2010 codified the practice; Mike Burrows's Kanban from the Inside and Klaus Leopold's Practical Kanban extended it. The patterns below have stabilized through a decade of practice in software teams.

The Basic Column Pattern

The minimum useful board has three columns:

• To Do — work waiting to be started.
• In Progress — work currently being done.
• Done — work completed.

This is sufficient for the simplest teams. For most teams, it's insufficient because it doesn't model the actual stages work passes through.

Expanded Columns

Most real workflows have several distinct stages:

• Backlog — unsequenced ideas.
• Ready (or "Next") — refined, prioritized, ready to start.
• In Progress — actively being worked.
• In Review — code review, design review, etc.
• Testing — QA or acceptance testing.
• Ready for Deploy — awaiting release.
• Done — in production.

The right column set depends on the team's actual workflow. The discipline is to make the columns match how work really moves, not how someone hopes it moves.

Doing vs. Done Sub-columns

One of the most useful patterns: split each work column into "doing" and "done" sub-columns. A "Review (doing)" column shows items being actively reviewed; a "Review (done)" column shows items finished with review and waiting for the next stage. The split exposes the waits that single-column boards hide.²

The cumulative effect: when "doing" sub-columns are short and "done" sub-columns pile up, the bottleneck has been visualized. Without the split, the same items appear simply as "in review."

Ready Queues

A "Ready" column (also called "Next" or "Selected") sits between Backlog and In Progress. Its purpose: hold a small, refined, prioritized set of items the team can pull from. The Ready column has its own WIP limit — typically 5–10 items.

The Ready column is one of the most impactful additions to a basic board. It separates what we will work on next from everything we might do someday, and it forces refinement before pulling rather than refinement during work.

Expedite Lanes

A dedicated lane (often at the top of the board, visually distinct) for urgent items that bypass the normal queue. The expedite lane has a WIP limit of 1 — only one expedite item in flight at a time. This is what makes the lane work: it preserves the ability to handle emergencies without making everything an emergency.

Blocked Visualization

Cards that are stuck — waiting on someone, blocked by a dependency, broken — should be visually marked. A red dot, a flag icon, or a "blocked" tag works. The discipline of marking blocked items immediately makes wait time visible in a way the column-only view doesn't.

Explicit Policies

Each column should have a posted, visible policy: what does it mean for a card to be in this column, what's required to enter, what's required to exit?

Example for an "In Review" column:

• Entry: developer has marked the PR ready for review.
• Exit: at least one approval, all comments resolved, CI passing.
• WIP limit: 4.
• Aging policy: any item older than 2 days requires a swarm decision.

Without explicit policies, columns mean different things to different team members and the board's signal value drops.

Common Failure Patterns

• The board doesn't match reality. Cards stay in "In Progress" for a week because there's no column for "waiting on QA." Add the missing stages.
• Too many columns. A board with 12 stages becomes unreadable. If reality has 12 stages, that's itself a smell worth addressing.
• No WIP limits. The board records work but doesn't constrain it. Lower WIP is the actual purpose of the board.
• "Doing" without "Done" sub-columns. Waits stay hidden inside work stages.
• Stale Done columns. Cards accumulate forever. Move them off-board after the next cadence point.

Coaching Tips

Map reality first.

Walk through an actual recent feature. Note every stage and wait. Build columns to match. Don't design the board you wish you had.

Add Doing/Done sub-columns.

The single highest-leverage change. Waits become visible immediately.

Post column policies visibly.

Entry, exit, WIP limit, aging policy. If they're in a wiki, they don't exist. Print and post.

Mark blocked items immediately.

Red dots, flags, anything. The first day a card is blocked is when intervention is cheapest.

Treat expedite lane WIP as sacred.

If two expedites run in parallel, both lose their priority. The single-item limit is the mechanism.

Audit the board every quarter.

Columns become stale as work evolves. Refresh the model periodically.

Summary

A well-designed kanban board is a working model of how a team produces value. Column structure, sub-column splits, ready queues, expedite lanes, blocked visualization, and explicit policies all combine to make the system visible and steerable. The board's value is not the rendering of work but the signals it generates — bottlenecks emerging, aging items, queues piling up. Teams that invest in their board's design produce more accurate forecasts and faster cycle times than teams who treat the board as a Jira default.

Back to Flow & Forecasting