How to Build a Kanban Board for Clear, Visual Work Tracking

A Kanban board makes two things visible that a task list hides: where work is stuck, and how much of it is in flight at once. You get most of the value from columns that match how work really moves and a limit on the busiest one — neither of which requires adopting a project-management platform.

Live interactive diagramUse the player controls to follow the steps

Software sprint boardPlaying silently in this guideWatch with narrationOpen in editor

When a board beats a list

Use a board when work arrives continuously and moves through stages — support, bugs, hiring, content. Use a Gantt chart instead when the work is a one-off project with dependencies and a date; see building a release plan.

What a good board contains

• Columns that are real states, not wishes. If work always waits for review, “Waiting for review” is a column. Hiding a queue inside “In progress” hides the only number that matters.
• An explicit definition of done for each column. What has to be true before a card moves right.
• A work-in-progress limit on at least the busiest column. Without one, a board is a to-do list arranged horizontally.
• Cards sized to finish in days, not weeks. A card that never moves teaches people to stop looking.
• A visible entry policy. Where new work comes from, and who may add it.

Boards you can open and adapt

Building one in Diagramium

1. Open the closest board above and rename the columns. Start with the four you actually use.
2. Add the queue columns you have been pretending not to have. This is usually the change that makes the board useful.
3. Drag cards across to move them. In the Kanban editor the column owns the horizontal position, so a card dropped in a column belongs to it — a card cannot end up between states.
4. Write the WIP limit into the column name — “In progress (3)”. A limit that is not on the board is not a limit.
5. Use step notes for the definition of done per column, so the rule lives with the board.
6. Press Present for stand-up to walk the board column by column instead of person by person — it keeps the conversation on the work.
7. Export as PNG for a weekly summary, or embed the board in a team page. Everything is stored on your device, so a board of internal work never leaves it.

Design recommendations

• Five columns or fewer to start. Add one only when you can name the queue it exposes.
• Colour by class of work, not by person — expedite, standard, maintenance.
• Put Done on the right and archive it regularly. A Done column with two hundred cards makes the board slow to read.
• Keep card titles short enough to read at a glance; detail belongs in the note.

Common mistakes

• Columns that mirror the org chart. “Dev”, “QA”, “Ops” describe who holds the card, not what state it is in — and the queue between them stays invisible.
• No WIP limit. Then the board records the overload instead of preventing it.
• A permanent “Blocked” column. Blocked is a flag on a card, not a place work lives.
• Cards that outlive the quarter. Split them, or accept the board is fiction.
• Nobody looking at it. A board is a conversation prop; if it is not used in stand-up it will drift within a week.

The checklist

Run this before you share it.

1. Columns are states, and every real queue has its own.
2. Each column has a written definition of done.
3. At least the busiest column has a visible WIP limit.
4. Cards are small enough to move within days.
5. The entry policy is written down.
6. Done is archived on a schedule.
7. The board is used in a recurring meeting.
8. The editable original is somewhere the team can reach.