Setting Up a Kanban Board in 30 Minutes: Columns, Limits and Rules

Setting up a kanban board means drawing the path your work already takes, capping how much can sit in each step, and writing down when a card is allowed to move. You don't need a new process or a tool migration. Thirty minutes is enough if you copy the work that's already in chat and tickets, then add limits.

For the longer explanation of columns, cards, and flow, read What Is a Kanban Board? A Practical Guide for Software Teams. This piece covers only the setup.

Setting up a kanban board: the three pieces

A board comes down to three decisions.

1. Columns are the states work passes through. They show where a card is, not who owns it.
2. WIP limits set the maximum number of cards allowed in a column. Without a limit, a column is just a list.
3. Policies are the rules for entering and leaving a column. If two people would move the same card differently, you're missing a policy.

Skip swimlanes, classes of service, and extra fields on day one. Add them after a week of real cards, once a split would actually change a decision.

What the board is for

The board is a shared picture of work in progress, with a cap so the team finishes things before starting new ones. It isn't the backlog, the roadmap, or the status report. It holds the work someone is touching right now, plus the next few items that are ready.

That's why basic kanban is four columns and a number on each middle column. A crowded board fails the glance test, because nobody can tell what is allowed to move.

You can tell the board is working from two things. A blocked card is visible without anyone calling a meeting, and starting something new requires finishing or unblocking something else. If both hold, imperfect column names can wait. If either one doesn't, rename and recap before you automate anything.

Columns worth keeping

Use the fewest columns that match how work changes hands:

Column	What belongs here	Typical WIP
Ready	Specified enough to start. Nobody is on it yet.	4 to 8
In progress	Someone is changing the code or the doc.	One per person
Review	Waiting on review, QA, or a decision.	Half of In progress
Done	Accepted this cycle. Cleared on a schedule.	No limit

Column names that cause bad moves

"To do" as column one. It turns into a second backlog. Call it Ready, and only pull items that meet the entry rule.

A column per person. That's a status wall. Ownership belongs on the card, so the column stays the same when someone else picks up the ticket.

"Blocked" as a parking lot. A blocked card should stay where it stalled, with a flag on it. Moving it sideways hides it from the WIP count. Kanban Flow: How Work Should Move Across Your Board goes into more detail on what "move right" should mean.

A Done column that never empties. Hide cards on a fixed day, either Monday or the end of a cycle. When Done gets huge, people learn to ignore the right side of the board.

Ops and support boards often use different names, such as Inbox, Doing, Waiting on customer, and Resolved. Each column still needs an exit rule you can say in one sentence. If four columns feel too tight, 12 kanban board examples shows other software and ops layouts.

WIP limits you will keep

Base the first limits on headcount.

• In progress: one card per person who builds. Five people means a limit of 5. If pairing is your normal way of working, count streams of work, not names.
• Review: half of In progress, rounded down. Review grows without a limit because starting work feels useful and reviewing doesn't.
• Ready: roughly a week of pull. If it sits full for two weeks, either the limit is too high or the entry rule is too loose.

Write the number on the column header.

When a column is full, the next move is to finish or unblock a card in it. Pulling from the left just because someone is free isn't allowed. The rule feels harsh for about a day, but it's what keeps waits visible while they're still small.

You will break a limit at some point. When you do, note who agreed and why, and look at the exceptions in the next standup. If nobody is ever allowed to break a limit, the limit turns into fiction. If everybody breaks it quietly, it turns into a suggestion.

If a deadline lands on a full column, you have three options: finish the oldest card there, shrink the new request, or raise the limit for one day and then put it back.

Policies, one line each

Write the entry rule under the column name.

• Ready: the outcome is written, dependencies are named, and someone who missed the meeting could start.
• In progress: an owner is named and the branch or doc is open.
• Review: the author has stopped and asked for review. The card stays here until the comments are resolved or the reviewer accepts it.
• Done: merged, deployed, or accepted by the requester. Pick one and write it down.

Once ten cards have crossed the board, delete any rule that never changed a move. If people still ask which column a card belongs in, the rule for that column is too vague.

A worked example

Northwind is a made-up team of four engineers, one designer, and one product manager. They already have tickets.

Their columns are Ready (6), In progress (4), Review (2), and Done (cleared Monday). For policies, Ready needs a short outcome and a link to the design or the repro, In progress needs an owner and an open change, Review needs a named reviewer, and Done means merged to main.

On Monday they place the nine tickets they touched last week. Three land in Review, which is over the limit of 2. Instead of raising the limit to match history, they finish or return one review card before anyone pulls from Ready. Two ideas have no outcome, so they go back to the backlog. One ticket is blocked on a vendor. It stays in In progress with a flag, and it still counts toward the limit of 4.

They leave out a few things. There's no QA column, since the same person reviews and tests. There's no priority swimlane, because they sort Ready by hand, and no expedite class, because nothing has been a real interrupt this month. They also skip story points, since the board is there for flow.

By Thursday, Review is where work waits. They change a policy rather than the columns: small changes get reviewed the same day, and larger ones get a booked slot. The limit stays at 2.

The 30 minutes

Do this with the people who actually move cards. Setting up a kanban board on your own means you'll be redrawing it tomorrow.

Minutes 0 to 8. List this week's real tickets, somewhere between ten and twenty cards. Leave everything else in the backlog.

Minutes 8 to 15. Name the columns from the table. Only rename one if there's a real handoff behind it, and don't add a column for a rare case.

Minutes 15 to 22. Put numbers on the headers. In progress equals the number of work streams, Review is half of that, and Ready is about a week.

Minutes 22 to 28. Write four policies, one sentence each. If a sentence doesn't apply to a card on the table, rewrite it.

Minutes 28 to 30. Move cards until you hit a limit. Everything else waits. Agree on when Done gets cleared.

Run the board for five working days before you add a field or a fifth column. Then ask which column was full most often. That column is your constraint, so change its policy or its staffing before you redesign anything.

Pick a tool, then stop

A wall, a spreadsheet, or the product you already pay for can all hold this board. They fail the same way: cards multiply, limits stay blank, and Ready turns into the backlog.

Trello kanban boards are quick for a first layout but get thin once the backlog has to stay separate from Ready. Jira kanban boards can express limits precisely, though they punish a team that copies every status into the workflow on day one. Atlassian's kanban guide lays out cards, columns, and WIP plainly if you want that model written down.

From the tool, you need three things: renaming a column, showing a WIP number, and filtering to your own cards plus blocked cards.

Slack messages, call notes, and production errors still have to become cards that meet the Ready rule. Falrow handles that with triage and explicit stages in the ticket workflow, so work that isn't ready never lands on the board. If you later want those same cards to feed a cycle and a forecast, how the delivery loop runs covers that, and you can decide on it later. The columns, limits, and policies above work without it.

FAQ

How many columns should a new kanban board have?

Start with four: Ready, In progress, Review, and Done. Add a column only when a handoff has its own queue and its own exit rule. Extra columns usually split one person's work into two boxes, which makes the limits easier to dodge.

What is a good WIP limit for a small team?

Set In progress to the number of people who can move a card today, and Review to about half of that. Four engineers often end up at 4 and 2. Adjust after a week of watching which column stays full.

How is a kanban board different from a to-do list?

A to-do list can keep growing without anything getting finished. A kanban board caps each state, so a new card moves only when a slot opens up. The columns also separate waiting from doing, which a single checklist can't.

Can we set this up if work arrives as interrupts?

Yes. Keep the columns, and write down who is allowed to preempt a card and which card leaves In progress when they do. If nearly everything is an interrupt, triage it before Ready. The board should only show accepted work.

Put the columns up, write the limits on them, and change the policy on whichever column stayed full.