How many columns should a kanban board have

Three. To Do, In Progress, Done.

That is the right answer for most software teams under about ten people. The rest is the reasoning, because the number alone will not survive the first person who says "but we need a column for review". You are done when you can point at every column and name who moves cards out of it.

Columns are a compression of your process, not a description of it

Atlassian's definition is the useful one: "Each column represents a specific activity that together compose a 'workflow'", and workflows "can be as simple as 'To Do,' 'In Progress,' 'Complete,' or much more complex" (atlassian.com). The Kanban Guide, in its May 2025 revision, prescribes no number at all. Its minimum is "One or more defined states that the work items flow through from started to finished" (kanbanguides.org). The floor is one state, and nobody will tell you the ceiling.

Which is why teams get this wrong: every column looks free when you add it. On that same page, Jim Benson is quoted arguing that kanban has two rules — limit work in progress, visualise your work — and that "The more rules you add, the less contexts it fits into". A column is a rule. It says work stops here, something happens, then it moves on.

How many columns a kanban board should have, in one test

For every column, name the person who pulls cards out of it and the signal that tells them to. If you cannot, the column is not a state. It is a queue wearing the costume of a state.

The Kanban Guide requires, as a minimum element of a Definition of Workflow, "Explicit policies about how work items can flow through each state from started to finished" (kanbanguides.org). On a team of five, an explicit policy is not a document. It is a name and a trigger.

In Review is the usual offender. Review is real work, but the column has no owner: the assignee has finished with the card and the reviewer has not started, so nobody experiences the delay as theirs.

The two columns worth adding when the pain shows up

A column for a specialist. Atlassian's WIP guidance says it outright: if your team has specialists, "Create a status specific for the specialist's work" (atlassian.com). It passes the test by construction: if one person is the only one who can do the thing, the column has an owner the moment it exists. Ready for QA on a team with a tester is a state. Ready for QA where testing is whoever wrote it is a queue.

A column for work that has left your hands. Waiting on a customer, a deploy window, somebody else's legal review. Not for tidiness: that work otherwise sits in In Progress and inflates the only number on the board anyone reads, which is how much is genuinely in flight. It has an owner too, whoever chases the outside party.

Blocked is almost always a mistake

Blocked fails the test in an unusually bad way, because it looks like it passes.

The Kanban Guide lists "Unblocking blocked work" as a form of actively managing items in a workflow (kanbanguides.org) — an activity somebody performs, not a place a card lives. It also defines work in progress as everything between a started and a finished point, so a card dragged into Blocked is still work in progress. You have not reduced the load. You have relabelled it.

What actually happens is subtler. Before the column existed, a blocked card sat in In Progress with somebody's name on it, and the discomfort was the mechanism. Once Blocked exists, the conversation becomes a status change instead. Atlassian's own list of WIP anti-patterns includes raising the limit until the team stops hitting it (atlassian.com); a Blocked column is the same move with better manners.

In fairness: on a large board with somebody whose job is chasing blockers, Blocked earns its place. At five people that person is already in the conversation. Use a flag instead, and let the card keep counting against what is in flight.

Sometimes the question is really how many boards

Watch for a column you want because of what the work is rather than what state it is in: one for the mobile stuff, one for support. That is a filter or a second board, and an Ask HN thread on one mixed backlog names the cost: "Putting unrelated things on the same board is expensive, because you have to constantly compare those apples and oranges" (news.ycombinator.com). Reaching for a column when what you wanted was a different view is its own mistake.

What a tool can do about this, and what it cannot

Not much. No software knows whether your In Review has an owner. What it can do is make the default cheap to change, which matters when the alternative is an admin nobody volunteered for.

Since we build one, here is ours with the awkward part left in. A new Kevta board arrives configured — Title, Assignees, Status, Priority, Due Date — and Status ships with five options rather than three: To Do, In Progress, In Review, Ready for QA, Done. Two more than this post recommends, and for a mechanical reason: the GitHub rules that come with a board need somewhere to write, since a pull request opening moves an issue to In Review and an approval moves it to Ready for QA. If you are not connecting a repository, delete the two you cannot staff. Status is an ordinary select property, so its options are yours to rename, reorder and delete in the board's settings. Kevta does not enforce WIP limits, so that discipline is yours.

One habit worth stealing regardless of tool: the same issues read as a board, a list, a table or a calendar, switched with a keypress. Plenty of columns exist only because somebody wanted due dates in order — a view, not a state.

The rule

Three columns until a fourth has a name attached to it. Add it when somebody is visibly the person who moves cards out of it, not when it comes up in a retro. Do not add Blocked.

If you would rather start from a board that is already configured, Kevta is in beta and you can join the waitlist.