A small team of two to ten people needs one shared kanban board with four columns, a work-in-progress limit, and a five-minute daily stand-up. That is the whole system. Everything past those three things is process the team is paying for without getting speed back.
The failure mode small teams actually hit is not "no process." It is borrowing a framework built for a fifty-person org: story points, sprint ceremonies, a board per sub-team, an integration for every tool in the stack. Each piece looks reasonable on its own. Together they add a second job that nobody was hired to do.
Four columns, one board
Every person on the team sees the same board and can move any card on it. A separate board per person defeats the point, because the reason to use kanban at all is to stop reconstructing status from five people's memory.
Backlog | To Do | In Progress | Done
Backlog holds everything not yet prioritized. To Do holds what the team committed to for the current week. In Progress holds active work, capped at roughly one card per person. Done holds what shipped, cleared out once a week rather than left to grow into an archive nobody reads.
A fifth column earns its place only when a real stage is being hidden inside "In Progress", most often a review or QA step where work sits waiting on someone else. Add it when that happens, not before. Kanban board examples walks through a few of these variations if four columns turns out not to fit how the team's work actually moves.
A WIP limit the team will actually keep
The single change that does the most work is a cap on In Progress. For a five-person team, three to five active cards is a reasonable start: enough that nobody sits idle, tight enough that starting a sixth thing means finishing one of the first five first.
Without the cap, the easiest response to a new request is to start another card, and the board fills with half-finished work while completion does not improve. With the cap, a full column is itself useful information: it means help the blocked cards or clarify priorities before adding more. Atlassian's guide to WIP limits covers the mechanism in more depth, and WIP limits explained covers how to pick a first number and adjust it once the board shows real data.
The five-minute stand-up
A stand-up is a coordination check, not a status meeting. Three questions, said out loud, pointing at the board rather than describing it from memory:
- What moved to Done since yesterday
- What is in In Progress right now
- What is blocked
That takes under five minutes for a team of five, and it should feel slightly redundant, because the board already shows most of it. Anything that turns into a discussion gets a note on the card and a conversation afterward with just the people it concerns.
Weekly planning in thirty minutes
Once a week, usually Monday morning, look at Done and clear it. That is not busywork. Reading a week of finished cards before planning the next one keeps the team anchored to what actually happened instead of what was supposed to happen.
Then pull the next batch from Backlog into To Do, ordered top to bottom by priority, and check whether the pull is realistic given last week's pace rather than this week's optimism. A team that finished six cards last week and pulls fifteen this week has already decided which nine will be disappointments.
What a card needs, and what it does not
A card needs a title specific enough to picture finishing ("fix the login redirect on Safari," not "login") and an owner. Everything else is optional and most of it should stay that way: a one-line description if the title alone is not enough, a due date only when one genuinely exists, a tag for the area of the codebase or the project it touches.
Skip time estimates. On a small team they are rarely accurate enough to plan around and mostly measure how confident someone felt on Monday. Skip custom fields for the same reason a fifth column should wait: add one only after the same missing information causes a problem twice, not because it might be useful once.
What this looks like at different sizes
Two or three people barely need a board at all, and a shared list covers most of it. If a board still helps for visibility, three columns and no WIP limit are enough, because everyone can already see everyone else's plate.
Five to eight people is where this setup earns its keep exactly as described above. Ten to fifteen people usually means splitting into two boards along a real seam, frontend and backend or product area, while keeping each one this simple. Past twenty, coordination between teams becomes its own problem, and that is a different guide than this one. Most small teams never reach it, which is the point: build the heavier version when a specific problem forces it, not because the team crossed a headcount milestone.
Moving off a heavier tool
Run the new board alongside the old one for a week without migrating everything. See whether the team reaches for it on its own. In week two, ask directly what feels missing rather than assuming, and fix that specific gap instead of adding a general safety margin of extra fields and columns. If the board held up, migrate the active work and archive the old tool in week three rather than running both indefinitely, since a board nobody has to check stops being checked.
Frequently asked questions
How many columns should a small team's kanban board have?
Four: Backlog, To Do, In Progress and Done. Add a fifth only when a specific stage, usually review or QA, keeps getting hidden inside In Progress and the team needs to see it separately.
What is a good WIP limit for a five-person team?
Start around three to five cards in In Progress, roughly one per person, and watch where work waits for a week before adjusting. The number matters less than having one at all.
Do daily stand-ups still make sense with a shared board?
Yes, kept to three questions and under five minutes: what moved to Done, what is active, and what is blocked. The board should make most of the meeting feel unnecessary, which is the sign it is working.
Should a small team use story points or estimates?
Usually not. Estimates on a small team are rarely accurate enough to plan around, and the effort spent producing them beats their usefulness. Track what actually shipped each week instead and plan the next week against that pace.
When does a small team need more than one board?
Around ten to fifteen people, once two sub-teams stop needing visibility into each other's day-to-day work. Split along a real seam, such as frontend and backend, rather than splitting by habit.
Related reading
- WIP limits explained: a practical Kanban guide
- Kanban board examples: 7 column layouts that work
- Choosing a project management tool for startups
Small teams win by shipping, not by running a well-documented process. Four columns, one limit, and a five-minute stand-up cover most of what a team of this size actually needs from a board.