What is a kanban board? A practical guide for software teams
Quick answer
A kanban board is columns of workflow states and cards that move through them, with a hard limit on how many cards can be in progress at once. Here's what actually matters and what's just decoration.
By PlanodaEditorial
Key takeaways
- A kanban board visualizes work as cards moving left to right through columns that represent real workflow states, but the feature that actually changes behavior is the work-in-progress limit, not the columns.
- Kanban was adapted from Toyota's manufacturing pull system to software work by David J. Anderson in the mid-2000s, and the software version kept the core idea: don't start new work until something finishes.
- Kanban is continuous flow with no fixed iteration; Scrum is timeboxed sprints with a fixed commitment — they solve different problems and a team can run either on the same underlying issue tracker.
- The two most common failure modes are an unlimited WIP column that turns the board into a wish list, and columns that describe an aspiration ('Blocked', 'Prioritized') rather than a state work actually sits in.
A kanban board is a set of columns representing the stages work moves through, and cards representing individual pieces of work, each sitting in exactly one column at a time. That's the whole visual idea, and it's simple enough that most teams stop there. The part that actually changes how a team behaves — and the part most boards skip — is a hard limit on how many cards are allowed in an in-progress column at once. Without that limit, a kanban board is just a nicer-looking to-do list. With it, it's a tool that forces a real conversation about focus.
Where it came from
Kanban started as a scheduling system on Toyota's factory floor, where a physical card ('kanban' is Japanese for 'signboard') signaled that a production station had capacity for more work, pulling material through the line instead of pushing it based on forecast. David J. Anderson adapted the same pull logic to software teams in the mid-2000s, and the version that stuck kept the essential mechanic: a station — or an engineer — doesn't take on new work until it has room. Everything else about the modern software kanban board (the columns, the swimlanes, the digital cards) is presentation on top of that one constraint.
Kanban vs Scrum, honestly
These get treated as rivals when they're really answers to different questions. Sprint planning and Scrum timebox work into fixed iterations with a committed scope — useful when a team wants a regular cadence to plan, demo, and reset. Kanban has no iteration at all; work flows continuously, and 'done' happens whenever an item clears the board, not on a schedule. A support or platform team fielding unpredictable inbound requests usually fits kanban's continuous flow better than a fixed sprint commitment; a product team shipping a coordinated feature often prefers Scrum's rhythm. Plenty of teams run both on the same issue tracker — sprint cadence for planning, kanban view for the daily work — because the underlying data is the same regardless of which lens you look at it through.
The part that actually matters: WIP limits
A WIP limit caps how many cards can sit in an in-progress column at once — say, no more than three cards in 'In Review' for a five-person team. This sounds like a minor rule and functions like a forcing mechanism. When the limit is hit, nobody can start new work; the only options are to finish something or go help unblock whatever's stuck. That single constraint is what turns a board from a status display into a tool that surfaces bottlenecks the moment they happen, instead of a week later in a retro. A board with no WIP limit will happily show you fifteen cards 'in progress' at once, which is a nicer way of saying fifteen half-finished things and no clear picture of what's actually moving.
Columns should be states, not aspirations
The second thing that separates a working board from a decorative one is honest columns. A column should represent a state work genuinely sits in — 'In Review' means a pull request is open and waiting on a reviewer, full stop. It should not represent a hope, a priority, or a parking lot: a 'Blocked' column that everyone forgets to move things out of, or a 'Prioritized' column that's really just 'things we talked about once,' turns the board into decoration nobody trusts. If a card can sit in a column for a reason unrelated to what the column name says, the column is wrong, not the card. A good test is whether a new hire could look at the board and correctly guess what each column means without being told — if not, simplify it.
Where kanban stops being enough
A single kanban board answers 'what's the state of this team's work right now,' and it's genuinely good at that. It doesn't answer 'when will this ship' (that needs a delivery forecast, ideally a probabilistic one — see forecasting delivery without estimating a thing), and it doesn't scale to cross-team coordination on its own, because a board is a view of one team's work, not a portfolio. Those are the moments a team reaches for cycles, roadmaps, and dependency tracking on top of the board — not instead of it.
Putting it into practice
If you're setting up a board from scratch: start with the fewest columns that are still honestly distinct (three or four is usually enough — more than six is a sign some of them are really the same state), set a WIP limit low enough that it actually gets hit occasionally, and revisit both after a couple of weeks of real use rather than trying to design the perfect board on day one. Boards and issues living on one schema means the board is just one view of the same underlying issues your reports, roadmap, and triage queue already use — see it in action with the triage tool, which shows how incoming requests land on a board without anyone manually sorting them.