A Kanban board visualizes work flowing through a process, with columns representing stages and cards representing work items. The board’s design directly affects whether the team uses it effectively or ignores it. A board with three generic columns (To Do, Doing, Done) is barely better than a task list. A board designed to match your actual workflow, with WIP limits and explicit policies, becomes the team’s central coordination tool.

Kanban Board Setup Guide: Design a Board That Actually Works

Kanban originated in Toyota’s manufacturing system and was adapted for knowledge work by David Anderson in the mid-2000s. The core principles are simple: visualize work, limit work in progress, manage flow. The board is the primary tool for all three.

Designing Your Columns

Columns should represent the actual stages work passes through, not an idealized process. Observe your team’s real workflow for a week before designing the board.

Common Column Patterns

Software Development Team:

Backlog → Ready → In Development → Code Review → QA Testing → Done

Marketing Team:

Requests → Approved → In Progress → Review → Published

Support/Ops Team:

New → Triaged → In Progress → Waiting on Customer → Resolved

Column Design Rules

Each column should represent a distinct activity. If two columns describe the same type of work by the same people, merge them.

Include “waiting” states explicitly. Work that is sitting between activities — waiting for code review, waiting for design feedback, waiting for a vendor response — should be visible. A “Waiting for Review” column (or sub-column) reveals bottlenecks that a single “In Progress” column hides.

Do not overdo it. Five to seven columns is the sweet spot for most teams. More than eight creates visual clutter and makes the board hard to scan. Fewer than four does not provide enough workflow visibility.

Backlog vs. Ready

Separate the backlog (everything that might be done someday) from the ready queue (items groomed and ready to start). Only items that meet the team’s definition of ready — clear description, acceptance criteria, dependencies resolved — move to “Ready.”

This separation prevents partially-defined work from entering the active workflow and causing delays mid-process.

Setting WIP Limits

WIP (Work In Progress) limits are the defining feature of Kanban. They cap the number of items allowed in a column at any time. When a column is at its WIP limit, no new items can enter until one exits.

Why WIP Limits Matter

Without WIP limits, teams start many items and finish few. Work piles up in “In Progress” and cycle time increases. WIP limits force the team to finish work before starting new work, which:

• Reduces context switching (fewer active items per person)
• Exposes bottlenecks (when a column fills to its limit, upstream work stops, forcing attention to the bottleneck)
• Improves cycle time (items flow through faster when the team focuses on completion)

Setting Initial WIP Limits

A starting formula: WIP limit = Number of people working in that stage + 1 buffer.

If three developers handle “In Development,” set the WIP limit to 4. If one QA engineer handles testing, set the QA limit to 2. The +1 buffer allows for overlap when one item finishes and the next starts.

These limits are starting points. Adjust based on observed flow:

• If the team frequently sits idle because the incoming column is empty, increase the upstream WIP limit.
• If items pile up waiting to enter a column, decrease the upstream limit or increase capacity in the bottleneck column.

Handling WIP Limit Violations

When a column reaches its WIP limit, the team faces a choice:

1. Swarm. Help clear the bottleneck. A developer might assist with code review, or a designer might help with QA testing to unblock the flow.
2. Wait. Work on other activities (documentation, tech debt, learning) until space opens.
3. Escalate. If the bottleneck is systemic (QA is always the constraint), discuss resource allocation changes in the next retrospective.

Card Design

Each card on the board should convey enough information to understand the item at a glance:

Essential card fields:

• Title (clear, descriptive)
• Assignee (who is currently working on it)
• Priority indicator (color, icon, or label)
• Age indicator (days since the card was created or entered the current column)

Optional but useful:

• Blocker flag (visual indicator that the item is blocked)
• Type (feature, bug, tech debt, support)
• Size estimate (if the team estimates)

Most tools (Jira, Trello, ClickUp, Monday.com) support customizable card appearance. Configure cards to show priority and blocker status without requiring the user to open each card.

Swimlanes

Horizontal lanes that segment the board into categories:

By type: Feature lane, bug lane, tech debt lane. Each type flows through the same columns but is tracked separately. This makes it easy to see how much capacity goes to each type of work.

By team member: Each person gets a swimlane. Their cards are visible in their lane. Useful for very small teams (2-3 people) where individual workload visibility matters.

By priority: Expedite lane at the top for urgent items (with its own WIP limit of 1-2). Standard lanes for normal-priority work. This ensures urgent items get immediate attention without disrupting the entire board.

Policies

Explicit policies define how cards move between columns. Write them on the board (physical) or in the column description (digital).

Example policies:

• “Ready” column: Item must have acceptance criteria, design mockup linked, and no unresolved dependencies
• “Code Review” column: PR must be submitted and reviewer assigned within 4 hours of entering this column
• “QA Testing” column: Item must include test cases. QA begins testing within 1 business day.
• “Done” column: Feature deployed to staging, tests passing, documentation updated, definition of done met

Written policies reduce ambiguity about what “In Review” means and when an item is genuinely “Done.”

Measuring Flow

Cycle Time

The time from when a card enters “In Development” (or the first active column) to when it reaches “Done.” Track cycle time per card and calculate the average. Decreasing average cycle time indicates improving flow.

Throughput

The number of cards completed per unit of time (per day or per week). Stable or increasing throughput with stable WIP limits means the system is healthy.

Cumulative Flow Diagram (CFD)

A chart showing the number of items in each column over time. The width of each band represents the amount of work in that stage. A widening “In Progress” band with a constant “Done” band indicates a growing bottleneck.

Most PM tools generate CFDs automatically. Review them weekly to spot trends before they become problems.

The Kanban board is not just a task tracker — it is a diagnostic tool for your team’s workflow. When designed with intentional columns, enforced WIP limits, and explicit policies, it reveals where work flows smoothly and where it stalls. That visibility is what enables continuous improvement sprint after sprint.