# How to set up a kanban board for a software team

> Set up a kanban board in eight steps: map your process, choose columns, size cards, set limits and review weekly. Includes column sets for software teams.

A kanban board only helps if it matches how your team really works. These eight steps take you from a blank board to one the team will keep up to date.

Web page: https://kansohq.app/guides/how-to-set-up-a-kanban-board

Updated: 5 October 2026

## Before you create the board

Sit down for twenty minutes with the people who do the work and trace one piece of work from idea to shipped. Write down each place it waits and each hand-off. That list is your draft columns. Starting from a template instead of your own process is the most common reason a board is abandoned after a month.

## The eight steps

1. **Map the real workflow.** Use the stages work actually passes through, not the ones in a process document.
2. **Choose the columns.** Fewer is better. Four to six columns cover most teams.
3. **Decide what a card is.** One task a person can finish in a few days. Bigger items become several cards or a spec.
4. **Set work-in-progress limits.** Start with the number of people on a column, or one fewer, and adjust after two weeks.
5. **Say what “done” means for each column.** For example, In review means a pull request is open and tests pass.
6. **Add the fields that matter.** Priority, owner and a due date are enough to begin with. Add more only when someone asks a question the board cannot answer.
7. **Fill it from the real backlog.** Move current work onto the board in one sitting, so the first day is accurate.
8. **Review it weekly.** Ten minutes: what is stuck, what is next, what can be removed.

## Column sets to start from

| Team | Columns |
| --- | --- |
| A small product team | Backlog, To do, In progress, Done |
| A team with code review and QA | Backlog, To do, In progress, In review, Testing, Done |
| A support or bug team | Reported, Triaged, Fixing, Verify, Done |
| A design and content team | Ideas, Drafting, Feedback, Approved, Published |

## Habits that keep a board honest

- The board is the plan. If work is happening that is not on it, add it or stop doing it.
- Move your own card the moment the work changes state, not at the end of the day.
- Archive finished cards on a schedule, so Done does not become a graveyard.
- When a column is over its limit, the team stops starting and helps finish.

## Signs the setup is wrong

- Cards sit in one column for weeks. The column hides a hand-off nobody owns.
- Everything is marked urgent. Use [Must, Should and Could](https://kansohq.app/guides/moscow-prioritization.md) so order means something.
- Nobody trusts it, so there is a second spreadsheet. Find out what the board cannot answer and add that field.

## A plan for the first two weeks

| When | What to do |
| --- | --- |
| Day 1 | Map the workflow with the team, create the board and move the current work onto it |
| Day 2 | Agree who moves cards, and say what each column means in one line |
| End of week 1 | Look at which column holds the most cards. That is where work is waiting |
| Day 8 | Set a first limit on that column, and say what the team does when it is reached |
| End of week 2 | Review: which columns are unused, which rules are ignored, what is missing |

## Adapting the board to other teams

The same method works outside software. A design team might use Ideas, Sketching, Review and Approved. A support team might use New, Waiting on us, Waiting on customer and Solved. A marketing team might use Brief, Draft, Review, Scheduled and Published. In each case, the columns are the real stages work passes through, and the limits go where work piles up.

## Metrics to look at after a month

- How long did cards take from started to done, and is it getting steadier?
- Which column did cards wait in longest?
- How many cards were open at the end of each week?
- How many cards were added mid-week, and how many of those were really urgent?

## Setting it up in Kanso

Create a board page in your project and rename the columns to match your process. Cards carry a priority (Must, Should or Could), owners, a due date and acceptance criteria. Put a limit on a column to be warned when it is passed. If you want another view of the same cards, switch to the table, list, timeline or calendar view and save it. See [Kanso Boards](https://kansohq.app/product/boards.md).

## Questions

### How many columns should a kanban board have?

Four to six for most software teams. Add a column only when work genuinely waits in that stage; a column nobody uses is noise.

### What should the work-in-progress limit be?

Start near the number of people working in that column, or one fewer, then adjust after two weeks of watching where cards pile up.

### How big should a card be?

Small enough that one person can finish it in a few days. If it takes longer, split it into several cards.

### How often should we review the board?

A short weekly review is enough: what is stuck, what is next and what can be removed. A daily glance during stand-up keeps it accurate.

## Keep reading

- [What is a kanban board? A guide for software teams](https://kansohq.app/guides/what-is-a-kanban-board.md): A kanban board shows work as cards moving through columns. Learn how it works, how it differs from scrum and how software teams use it well.
- [The MoSCoW method: Must, Should, Could explained](https://kansohq.app/guides/moscow-prioritization.md): The MoSCoW method sorts work into Must, Should, Could and Won’t. Learn what each means, how much to put in Must and how software teams use it.
- [Definition of done vs acceptance criteria](https://kansohq.app/guides/definition-of-done.md): A definition of done is a team-wide checklist every task must meet. Learn how it differs from acceptance criteria, with an example list to adapt.
- [Sprint planning template: goal, work and risks | Kanso](https://kansohq.app/templates/sprint-plan.md): A sprint planning template with the sprint goal, committed work, stretch, risks and what is out of scope. Copy it, or start it in Kanso.
- [Feature spec template with acceptance criteria | Kanso](https://kansohq.app/templates/feature-spec.md): A feature spec template with how it behaves, acceptance criteria, edge cases and what you are not doing. Copy it, or start it as a page in Kanso.

## Parts of Kanso used

- [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done.

[Kanso home, with plans and prices](https://kansohq.app/index.md)