Kanban

How to Set Up a Kanban Board: A Step-by-Step Guide

How to design a Kanban board that reflects your real workflow: columns, work items, WIP limits, swimlanes, classes of service, policies and example boards.

By Scrum Intelligence Team Published 13 min read
How to Set Up a Kanban Board: A Step-by-Step Guide

A Kanban board is the simplest and most visible part of Kanban, and one of the most useful tools any team can have. But a good board is more than columns with sticky notes. It reflects how work really flows, limits how much is in progress, and makes the team's rules visible. This guide shows you how to set up a Kanban board step by step, with example boards for different teams and the most common design mistakes to avoid.

Key takeaways

  • Design the board around how work really flows today, not an ideal process.
  • Decide what counts as a work item and where work starts and finishes.
  • WIP limits are what turn a task board into a Kanban system.
  • Write explicit policies so everyone knows when work can move.
  • Start simple and evolve the board as the team learns.

What is a Kanban board?

A Kanban board is a visual representation of a team's workflow. Each column represents a stage, each card represents a work item, and cards move from left to right as work progresses. The board shows at a glance what is being worked on, where work is waiting and where it is stuck. For the ideas behind Kanban, see our complete Kanban guide.

Common elements include:

  • Columns for the stages of the workflow
  • Cards for individual work items
  • WIP limits showing the maximum number of cards allowed in a column
  • Swimlanes separating different types of work
  • Blocker markers showing items that are stuck
  • Explicit policies describing the rules for each column

Physical or digital?

Physical boardDigital board
Best forTeams in one locationRemote or hybrid teams
StrengthsVery visible, easy to change, encourages conversationAccessible anywhere, records dates automatically, easy to share
WeaknessesHard to share remotely; data must be recorded by handEasy to over-complicate; less visible if nobody opens it

Many teams start with a physical board to design their workflow, then move to a digital tool once the design is stable. Popular tools include Jira, Trello, Azure Boards and many others. The tool matters far less than the design.

How to set up a Kanban board: step by step

Step 1: Decide what the board is for

Agree whose work the board covers and who its customers are. A board for one team's work is very different from a board for a whole department. Start with a single team or service.

Step 2: Define your work items

Decide what one card represents, such as a customer request, a feature, a bug or a piece of content. The Kanban Guide calls these units of value. If cards vary enormously in size, split large items so cards are roughly comparable. You may have several work item types; some teams show them with different card colours.

Step 3: Map your real workflow

List the stages work actually passes through today. Walk through a few recent items from start to finish and note every step, including waiting steps such as "waiting for approval". Resist the temptation to draw the process you wish you had. Kanban starts with what you do now.

Step 4: Mark where work starts and finishes

The Kanban Method describes a commitment point, where the team commits to doing an item, and a delivery point, where the item is delivered to the customer. Items to the left of the commitment point are options that may or may not be done; items to the right are in progress. These points define when cycle time starts and stops.

Step 5: Show waiting explicitly

Much of the time work spends on a board is waiting, not being worked on. Splitting a column into "doing" and "done" sub-columns, such as "Development: doing" and "Development: done", shows items that are finished at one stage but waiting for the next. This makes queues visible.

Step 6: Add swimlanes if needed

Swimlanes are horizontal rows for different types of work. Many teams use an expedite lane for urgent work that can jump the queue. Keep swimlanes to a minimum; too many make the board hard to read.

Step 7: Consider classes of service

The Kanban Method describes classes of service for treating work differently. Commonly used classes are expedite for urgent work, fixed date for items with a real deadline, standard for normal work and intangible for work with no immediate urgency, such as technical improvements. Each class has its own policy, for example "only one expedite item at a time".

Step 8: Set WIP limits

WIP limits are the maximum number of items allowed in a column, or across several columns, at once. There is no universal formula. A practical approach:

  • Count how many items are in each column today.
  • Set the initial limit at or slightly below that number, so the change is not a shock.
  • Lower limits gradually as the team gets used to finishing before starting.
  • Watch the effect on cycle time and adjust.

Some teams use the number of people who work on a stage as a starting reference. Whatever you choose, the limit only helps if the team respects it.

Step 9: Design your cards

Keep cards simple. Useful information includes a short title, the work item type, who is working on it, the date work started, and any deadline for fixed-date items. A clear blocker marker, such as a red sticker or tag with a short reason, helps the team spot stuck work immediately.

Step 10: Write explicit policies

Policies are short rules that everyone agrees to. Display them on the board. Examples:

  • "An item can move to Review only when all tests pass."
  • "Pull new work from Ready only when a WIP limit allows it."
  • "Blocked items are discussed first at the daily meeting."
  • "Expedite items are limited to one at a time."

Step 11: Start tracking dates

Record the date each item crosses the commitment point and the date it is delivered. With just these two dates, you can measure cycle time, throughput and work item age, the core Kanban flow measures.

Step 12: Walk the board and keep improving

Many Kanban teams hold a short daily meeting in front of the board. A common practice is to walk the board from right to left, starting with items closest to done, because finishing work matters more than starting it. Review the board design regularly and change one thing at a time.

Example boards

These are illustrations to adapt, not templates to copy exactly.

Software development team

OptionsReadyDevelopment (doing / done)ReviewTestingReleased
No limitLimit 5Limit 4Limit 2Limit 3No limit

IT support team

NewInvestigatingWaiting for customerFixingDone
No limitLimit 6Visible, not limitedLimit 4No limit

With an expedite swimlane for outages, limited to one item at a time.

Marketing content team

IdeasBrief agreedWritingDesignApprovalPublished
No limitLimit 4Limit 3Limit 2Limit 3No limit

Kanban board vs Scrum board

Scrum Teams often use a board for their Sprint Backlog, with columns such as To do, In progress and Done. It looks similar to a Kanban board, but there are differences. A Sprint board is usually reset every Sprint and limits work through what is selected in Sprint Planning. A Kanban board is continuous and limits work through explicit WIP limits. Many Scrum Teams add WIP limits to their Sprint board to improve flow within the Sprint. See Kanban vs Scrum for the full comparison, and Scrum artifacts explained for the Sprint Backlog.

Keeping the board healthy

  • Update it in real time. A board that is days out of date misleads everyone.
  • Keep every piece of work on it. Work handled off the board hides the real load.
  • Clear the Done column regularly. Archive finished items so the board stays readable.
  • Review ageing items. Items that have been in progress for a long time need attention.
  • Revisit the design. As the process improves, columns and limits should change too.

Running a board design workshop

The best boards are designed by the people who do the work. A simple workshop of an hour or two works well:

  1. Gather recent work. Bring ten to twenty items the team finished recently.
  2. Trace their journey. For each item, list every stage it went through, including waiting.
  3. Agree the common stages. Merge similar steps into a shared set of columns.
  4. Agree the work item types. Decide what one card represents and which types need to be distinguished.
  5. Mark the commitment and delivery points. Agree where work starts counting and where it is delivered.
  6. Set first WIP limits. Base them on what is in progress today.
  7. Draft a few policies. Start with three to five rules everyone agrees on.
  8. Agree when to review the design. For example, after four weeks of use.

Involving the whole team builds shared ownership. People are far more likely to keep a board up to date when they designed it themselves.

Showing blockers and dependencies

Blocked work is one of the biggest sources of delay, and it is easy to hide. Good boards make it impossible to miss:

  • Use a clear visual marker, such as a red tag, with a short reason and the date the block started.
  • Keep blocked items in their column, so they still count toward the WIP limit. This creates pressure to resolve them.
  • Show dependencies on other teams, for example with a note naming the team and what is needed.
  • Discuss blocked items first in the daily meeting.
  • Track how long items stay blocked. Recurring causes are strong candidates for improvement.

Using the board in the daily meeting

Many Kanban teams hold a short daily meeting at the board, often around fifteen minutes. Rather than each person giving a status update, the conversation focuses on the work and its flow. Useful questions include:

  • Which items are closest to done, and what do they need to finish?
  • What is blocked, and who can help unblock it?
  • Which items have been in progress longest?
  • Are any columns at or over their WIP limit?
  • Is anything at risk of missing a deadline or our Service Level Expectation?

Walking the board from right to left keeps the focus on finishing rather than starting.

Measuring with your board

A board with recorded start and finish dates gives you the core Kanban flow measures with very little effort:

  • Work in progress: count the cards between the commitment and delivery points.
  • Throughput: count how many cards reach the delivery point each week.
  • Cycle time: the time between an item's start and finish dates.
  • Work item age: how long an unfinished item has been in progress.

Most digital tools calculate these automatically. With a physical board, a simple spreadsheet is enough.

Boards across several teams

When several teams contribute to larger pieces of work, some organisations add a higher-level board, sometimes called a portfolio Kanban board. Its cards represent larger items, such as projects or major features, and its columns show stages such as proposed, approved, in progress and delivered. Limiting how many large items are in progress at this level often has an even bigger effect than team-level limits, because it stops organisations starting more initiatives than they can finish.

Tips for a readable board

  • Use short card titles that anyone can understand.
  • Limit colours to a few meaningful ones, and do not rely on colour alone to carry meaning.
  • Make WIP limits large and clear at the top of each column.
  • Keep policies short and visible.
  • If people need a legend to read the board, it is probably too complicated.

Evolving the board over time

A Kanban board is never finished. As the team learns, the board should change. As an illustration, a team's board might evolve like this over a few months:

  • After two weeks: the team notices items waiting for review are invisible, so it splits Development into doing and done sub-columns.
  • After a month: urgent requests keep disrupting everything, so the team adds an expedite lane limited to one item.
  • After two months: cycle time data shows items wait a long time in Testing, so the team lowers the Development limit to stop overloading testers.
  • After three months: the team merges two columns that always move together, making the board simpler.

Each change comes from evidence, not preference. That is the evolutionary approach at the heart of Kanban.

Example policies by column

These examples show the kind of short, clear rules teams display on their boards:

ColumnExample policy
ReadyItem has a clear description, agreed acceptance criteria and no known blockers.
In progressPull only when under the WIP limit; one owner per item.
ReviewReviewed by someone other than the author; feedback within one working day.
TestingAll agreed checks pass; any defects found are fixed before moving on.
DoneDelivered to the customer or released; finish date recorded.

A quick Kanban board checklist

  • Do the columns reflect how work really flows today?
  • Is it clear what one card represents?
  • Are the commitment and delivery points marked?
  • Does every in-progress column have a WIP limit?
  • Is waiting visible?
  • Are policies short, agreed and displayed?
  • Are start and finish dates recorded?
  • Is all current work on the board?

How often to review the board design

Many teams review their board design at a regular retrospective or service delivery review, perhaps every two to four weeks at first and less often once the design settles. Good triggers for a review include columns that are always empty or always full, items that regularly skip a column, frequent disagreements about where a card belongs, and new types of work arriving. Change one thing at a time so you can see its effect.

Common board design mistakes

  • No WIP limits. Without them, the board is a to-do list, not a Kanban system.
  • Too many columns. A board with fifteen columns is hard to read. Combine stages that rarely matter separately.
  • Columns for people instead of stages. Columns should show the workflow, not who does the work.
  • An ideal process on the board. If work does not really flow that way, the board will not reflect reality.
  • Hidden waiting. Without "done" sub-columns or waiting states, queues are invisible.
  • Too many swimlanes and colours. Every extra dimension makes the board harder to understand.
  • Setting the board up and never changing it. The board should evolve with the team.

Learn more

Our complete Kanban guide explains the principles, practices and metrics behind the board. For managing what comes into the board, how to manage a Product Backlog covers ordering techniques that apply to Kanban options too. If you want to build and demonstrate Kanban skills, Kanban Management in Systems Plus covers flow, WIP limits and flow metrics; the exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years.

Frequently asked questions

What columns should a Kanban board have?

Columns should reflect the real stages your work goes through. A simple start is To do, Doing and Done, but most teams add stages such as Ready, Review or Testing.

How do I set WIP limits?

Start with a limit at or slightly below the number of items currently in each column, then lower it gradually while watching cycle time.

What is a swimlane on a Kanban board?

A horizontal row that separates different types of work, such as urgent items or different products.

What is the commitment point?

The point where the team commits to doing an item. Cycle time is usually measured from here.

Should I use a physical or digital board?

Physical boards work well for co-located teams; digital boards suit remote teams. Many teams design on a physical board first, then move to a digital tool.

How many columns should a Kanban board have?

There is no fixed number. Use as many as needed to show the real workflow clearly, and no more.

What should go on a Kanban card?

A short title, the type of work, who is working on it, the start date and any deadline. Keep it simple.

Can a Scrum Team use a Kanban board?

Yes. Many Scrum Teams use a board with WIP limits for their Sprint Backlog.

Share this article: LinkedIn X
Scrum Intelligence Team

The Scrum Intelligence team writes practical guides on Scrum, Agile and certification. Our guides are based on the Scrum Guide (2020) and our own certification programmes.

Continue readingWIP Limits Explained: Why and How to Limit Work in Progress
🎓
Aria - Scrum Intelligence
🎓
Hi! I am Aria. Ask me about certifications, enrollment or salaries!
Which cert suits me?CSM vs PSM?How to enroll?