Most working kanban boards have three or four columns. The examples below are real column sets, starting with To Do, In Progress and Done, and ending with a sprint board and a client pipeline. The useful part of an example is not the picture, it is knowing which of those columns you can drop.
Galleries of board examples tend to grow: the further you read, the more columns each example has. This one runs the other way. Every layout here is one somebody maintains without a meeting about it.
The board almost everyone should start with
Three columns. To Do, In Progress, Done. Cards move left to right and nothing else happens.
It looks too simple to be worth setting up, and that is the point. The three column board answers the two questions a board exists to answer, which are what is waiting and what is being worked on right now. Start here and let the board tell you what is missing. Our guide to what kanban is covers the method behind it.
The mistake is designing the board you think you will need in six months. You will not need it, and you will have spent the first week filing cards instead of finishing them.
Seven kanban board examples
The first five are the column sets EasyKanban ships as templates, so they are layouts that get used rather than drawn for an article. The last two are the same shape adapted for work that spends most of its life waiting on somebody else.
| Board | Columns | Who it suits |
|---|---|---|
| General | To Do, In Progress, Done | Anyone starting out |
| Personal week | To Do, Doing, Done | One person, a week at a time |
| Sprint board | Backlog, In Progress, Review, Done | A small software team |
| Content calendar | Ideas, Drafting, Review, Published | Writers and marketing |
| Job search | Wishlist, Applied, Interviewing, Offer | One person, a pipeline |
| Client work | Enquiry, Quoted, In Progress, Waiting on Client, Invoiced | Freelancers and agencies |
| Support queue | Intake, Investigating, Waiting on Third Party, Resolved | Ops and support |
The first two rows are the same board. Doing and In Progress mean the same thing, so pick whichever word you would say out loud, then never rename it. A renamed column resets everyone's mental map of the board for a week.
The sprint board adds exactly one column, and it is Review. That column exists because code sits between written and merged for hours or days, and a board that hides that time hides the actual bottleneck. If your team argues about why releases are slow, a Review column usually ends the argument within a fortnight. The kanban board for developers post covers how sprint planning and bug triage sit on top of it.The last three rows are pipelines rather than workflows, and the difference is who moves the card. On a workflow board you move it when you finish something. On a pipeline board it moves when somebody else acts: they replied, they signed, they paid. Pipelines tolerate more columns for that reason, because each column marks a real event instead of a stage of effort. It is also why the support board carries a waiting column. Tickets blocked on a vendor otherwise look identical to tickets nobody has picked up.
How many columns should a kanban board have?
Three to five for work you do yourself, four to six for a team. Above six, the board needs somebody whose job includes maintaining it, and on most small teams no such person exists.
The official Kanban Guide is careful here. It describes columns as the steps and buffers in your workflow, and notes that a real system usually reflects more complexity than To Do, Doing and Done. That is true of a team with handoffs. It is not true of one person with a laptop, and the gallery articles rarely make the distinction because their examples are all sold to teams.
The number matters because every column is a question the person moving the card has to answer. Three columns is one obvious decision. Seven columns is a small filing problem, repeated every time anything happens, and the usual result is that cards stop moving. A board nobody updates is worse than no board, because it looks like a plan while being out of date.
What an extra column actually costs
A column looks free. You add it in a second and it holds as many cards as you like. The cost arrives later and lands somewhere else.
It lands on whoever moves the card. Every extra column widens the gap between where a card is and where a card should be, and widening that gap is what turns a board into a chore. It also lands on the next person to open the board, who now has to learn a vocabulary before they can read anything.
There is a third cost that is easy to miss. Columns that hold work indefinitely stop being stages and become storage. Review is the usual offender: it starts as a step and ends as the place cards go when nobody wants to decide. That is the case for a work-in-progress limit on that column specifically, and the Kanban Guide's definition allows one per state, per person or per lane, so you can cap the column that hurts without capping the whole board.
The test for a column that has to go
Look at the board and ask, for each column, when a card last sat there for more than a day.
If the answer is never, the column is not a stage. Cards pass through it on their way somewhere else, which means it records a moment rather than a state, and the board would read the same without it. Delete it and move its cards into the column on either side.
Two columns fail this test more than any other. The first is a Ready column sitting between the backlog and the work, which usually turns out to be the top of the backlog wearing a hat. The second is a Deployed or Archived column at the far right, which is a filing cabinet pretending to be a stage, and most boards already have somewhere to archive a card.
Run the test once a month. Boards only ever gain columns unless somebody removes one on purpose.
Should you use swimlanes?
Probably not yet. Swimlanes split a board into horizontal rows, usually one per person, per work type or per priority, and every gallery article recommends them. They pay off on a board with genuine parallel streams and a person responsible for it.
On a smaller board, a colour tag does the same job for less. Tagging cards by client or by type, then filtering to one tag when you want to look at it, gives you the separation without splitting the layout permanently. EasyKanban can also group every column by tag as a temporary view, which is the same lens without a change to how the board is arranged.
The honest version is that swimlanes solve a problem most boards do not have. Reach for them when two kinds of work genuinely never mix, not because a board with lanes looks more serious.
Four things that go wrong in week three
Setup is easy and every guide covers it. Week three is where boards actually fail, and it usually looks like one of these.
- Cards go in and never come out. The board became a to-do list with extra steps, which happens when nothing forces you to finish before starting.
- Review fills up. Nobody is refusing to review anything, there is just no limit and no policy, so it absorbs whatever arrives.
- Column names drift from what people say. If the team says "with the client" and the column says "External Approval", the column loses.
- The board stops matching how the work runs. Somebody changed a process in a meeting and no card ever crossed the new step.
None of these is fixed by adding a column, which is the instinct all four provoke. Three of them are fixed by removing one or capping it.
Where to start
Copy the closest layout in the table, use it for two weeks without changing anything, then run the removal test. Two weeks is long enough for a real bottleneck to show up and short enough that you have not built habits around a bad column.
If the board is for a team, agree what Done means before you agree what the columns are. Most column arguments are really an argument about Done, and naming it first makes the rest fast. Our simple project management page shows how the same layouts work with more than one person on the board, and the free plan covers three boards with up to three members each, which is enough to run the two week test properly.
Atlassian's kanban board overview is worth reading afterwards if you want the team scale version of the same argument.
Frequently asked questions
What are the most common kanban board columns?
To Do, In Progress and Done, in that order. Teams that need more usually add Review between In Progress and Done, or a Backlog to the left of To Do. Pipelines replace them with event names such as Applied, Interviewing and Offer, because each column marks something that happened rather than effort spent.
How many columns is too many on a kanban board?
Beyond six, someone has to own the board for it to stay accurate, and on a small team nobody does. Three to five works if you maintain the board yourself. Add a column only when work regularly sits in a state you cannot see, and remove any column where cards never rest.
Do I need a Backlog column?
Only if your To Do column has grown past what you can read at a glance. A backlog is a holding area for work you have accepted but not scheduled, which is useful for a team taking requests. For personal boards it usually duplicates To Do and adds a filing step for nothing.
What is the difference between a kanban board and a to-do list?
A to-do list records what to do. A kanban board also records what state each item is in and how much is happening at once, which is what makes bottlenecks visible. Without a limit on work in progress, a board behaves like a list arranged sideways and gives back very little.
Related reading
- WIP limits explained
- What is Kanban? A practical guide for beginners
- Kanban vs Trello: features, pricing and fit
- Google Sheets kanban template: build one that counts
A board is a description of how your work moves. When the description stops matching the work, change the board, and changing it usually means taking something out.