Kanban Board Design: Columns, Swimlanes and Cards

Kanban board design: structure columns, swimlanes and cards so the board shows how work really flows from commitment to delivery.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Kanban board design is the work of turning a team's real workflow into columns, lanes and cards that everyone reads the same way. The board is the visual form of the system. The Kanban Guide calls it the visualization of the Definition of Workflow and says there are "no specific guidelines for how a visualization should look," so the design is yours to fit your context (The Kanban Guide). What the board must do is make the minimum elements visible: the work items, where work starts and finishes, the states in between, how WIP is controlled, and the policies for moving items. See the Kanban method page for how the board fits the rest of the system.

Kanban University's guide stresses that the board should model the actual workflow "not a wishful future image" and that "each Kanban system and Kanban board are unique" (Official Guide to The Kanban Method). A board designed around the process the team wishes it had soon drifts from reality, and people stop updating it. A board that shows the waiting, the handoffs and the rework is uncomfortable at first and useful from then on.

A good design answers three questions at a glance. What is the team working on? Where is work waiting? What should happen next? Kanban board columns answer the first two, swimlanes separate kinds of work that need different treatment, and kanban card design makes each item understandable without opening a document. Everything else, such as colors and tags, should serve one of those questions or be left out.

This skill covers the first design and its early revisions. Pull policies, WIP limits and metrics each have their own skill, but the board has to leave room for all three, so they come up here too.

How It Works

Columns represent states that work items pass through. Kanban University's STATIK approach models the workflow after analyzing demand and capability, and describes the result as a board whose columns show the activities each work item type goes through, sequentially, in parallel or in no particular order. Two kinds of columns matter. Activity columns hold work being done. Queue or buffer columns, such as "Ready for review," hold work that is waiting. Splitting an activity into "doing" and "done" sub-columns shows when finished work is sitting idle before the next stage pulls it.

The board needs a clear commitment point and delivery point. Kanban University says every kanban system has "at least one clear commitment and delivery point." Items to the left of the commitment point are options the team has not agreed to deliver; items to the right are work in progress. Marking that line on the board keeps the backlog from being counted as work in progress and makes it obvious when an item has been committed.

Swimlanes are horizontal rows that group work. Kanban University notes that lanes are often used for different work types, projects or classes of service to distribute capacity. Kanban swimlanes earn their place when the team treats the lanes differently, for example an expedite lane with its own limit or separate lanes for planned and unplanned work. Lanes for each person tend to encourage individual queues instead of team flow, so use them with care.

Cards carry the information needed to act on an item. A useful card shows a short title, the work item type, the requester, any real deadline, the date the item was committed and a visible blocked marker. Colors or tags can show work type or class of service. Keep the card small enough to read from across the room or at a glance on a screen.

Digital tools impose their own constraints. In Jira, board columns are mapped to workflow statuses, and only items in the right-most column are treated as complete, so done-like statuses must map there (Atlassian, Configure columns). GitHub Projects can group items into horizontal sections by a field, and dragging a card to another group changes that field (GitHub Docs, board layout). Know these rules before you design, so the tool does not reshape your workflow by accident.

Step-by-Step Guide

Step 1: Map the workflow with the people who do the work

Bring together a representative group, as Kanban University recommends for STATIK, and trace a few recent items from request to delivery. Write down each state an item passed through and where it waited. Include rework loops and handoffs to other teams. Keep the language to states of the work, such as "In review," rather than names of people or departments.

Step 2: Group states into columns

Combine states that are always done together and separate those that involve a handoff or a wait. Add queue columns where work commonly waits, such as before review or deployment. Place an options area on the left and a finished column on the right. Aim for the fewest columns that still show where work waits.

Step 3: Mark the commitment and delivery points

Draw a clear line where the team commits to delivering an item, usually between the options area and the first active column. Mark where delivery happens, which may be before a final "Done" column if items wait to be released. These points define where cycle time starts and stops, so agree on them explicitly.

Step 4: Decide whether you need swimlanes

List the kinds of work the team handles and ask whether any need different rules. If urgent work must bypass the queue, add an expedite lane. If planned and unplanned work compete for the same people, lanes can make the balance visible. If no lane would change how the team acts, leave lanes out.

Step 5: Design the card

Choose the fields every card must show: title, work type, requester, commitment date, deadline if real, and a blocked marker. Pick one visual signal, such as color, for work type or class of service and use it consistently. Test the design by asking a teammate to explain a card they have not seen before.

Step 6: Leave room for limits and policies

Reserve space at the top of each column for its WIP limit and a short note of its entry and exit criteria. Put the fuller policy text next to the board. Kanban University recommends placing policies where they are clearly visible, preferably beside the board.

Step 7: Walk real items through the board

Take the items from Step 1 and move them across the new board. Check that each item has exactly one place to be at every moment and that no state is missing. Fix gaps now, while the board is still a draft.

Step 8: Launch and schedule a review

Put all current work on the board and start using it at the daily meeting. Agree to review the design after a few weeks. Watch for cards that sit in ambiguous places, columns nobody uses and work happening off the board, and change the design to fix them.

Best Practices

• Model the real process, delays included. Kanban University asks for the actual workflow, not a wishful future image, and a board that hides waiting cannot help reduce it.
• Name columns after states of work. "Awaiting review" tells people what to do next; a person's name only tells them who to ask.
• Make queues visible. Adding "ready" or "done" sub-columns shows where finished work waits for the next stage, which is often where most time goes.
• Keep swimlanes for different treatment. A lane should exist because the team handles its work differently, such as an expedite lane with its own limit.
• Show the commitment point. Separating options from committed work stops the backlog from inflating WIP and makes cycle time measurable.
• Treat the design as a draft. The Kanban Guide expects the Definition of Workflow to change, and the board should change with it.

Common Mistakes

• Designing the aspirational process: A board that shows how work should flow is soon ignored. Start with how it flows today and improve from there.
• Too many columns on day one: Modeling every edge case makes the board hard to read and maintain. Start with the stages where work waits and add detail only when the team needs it.
• Mixing options and committed work: When the backlog sits in the same columns as active work, WIP looks larger than it is and priorities blur. Mark the commitment point clearly.
• Lanes for each person: Personal lanes encourage individuals to guard their own queues instead of helping finish team work. Use lanes for kinds of work and track who is doing what on the card.
• Letting the tool dictate the workflow: Tool defaults such as a fixed three-column board rarely match real work. Configure the tool around the workflow you mapped.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Kanban

Related Skills

• Setting WIP Limits
• Creating Kanban Pull Policies
• Measuring Kanban Flow Metrics
• Choosing Kanban Software
• Managing Projects with Kanban
• Running Kanban Cadences
• Comparing Kanban and Scrum

Sources

• The Kanban Guide
• The Official Guide to The Kanban Method (PDF)
• Atlassian Support: Configure columns
• GitHub Docs: Customizing the board layout

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.