Scrum Board vs Kanban Board: Which One Fits Your Team
By Sebastiaan Jansen · · 9 min read
The scrum board vs kanban board choice comes down to cadence and commitment. The number of columns you draw has little to do with it. A Scrum board holds one sprint, then closes. A Kanban board stays open, caps work in progress, and pulls the next item when a slot frees up. Choose Scrum when the team can protect a timebox. Choose Kanban when new work arrives all week and waiting for the next planning meeting would itself be the delay.
Scrum board vs kanban board: the difference that matters
Scrum and Kanban boards both show work moving from left to right, so they can look identical. What separates them is the set of rules the team follows around the board.
A Scrum board is a picture of one sprint. The team picks a forecast in planning, works that set, and reviews what shipped. Unfinished items go back to the product backlog or into a later sprint, and that happens on purpose. The Scrum Guide fixes a sprint at one month or less. The board shows that sprint backlog, often as To Do, In Progress, and Done.
A Kanban board has no required reset. Each column has a work-in-progress limit, and someone starts work only when a slot opens. The same columns can stay up for months. Column design is covered in What Is a Kanban Board? A Practical Guide for Software Teams.
What changes when the rules change
| Scrum board | Kanban board | |
|---|---|---|
| Time boundary | Sprint opens and closes | No required boundary |
| Commitment | Sprint goal and forecast | None, or a service target you set |
| Work in progress | Capped by the sprint backlog | Capped per column or lane |
| New work mid-cycle | Avoided until the next sprint | Allowed when a slot is free |
| Useful measures | Sprint goal hit rate, finished items per sprint | Cycle time, throughput, age of cards |
| Planning event | Sprint planning refills the board | Replenishment when Ready runs low |
Two boards can have matching columns and still run different systems. If cards get added daily and the sprint never closes, you have a Kanban workload drawn as a Scrum board. If a Kanban board is locked between biweekly refills, it is a sprint with different nouns.
Bring this scrum board vs kanban board table to planning. Any row the team won't enforce is the row that turns the board into fiction.
When a Scrum board fits
A Scrum board fits when three conditions hold.
- The team can refuse most new work until the next sprint.
- The work can be sliced so a meaningful increment fits in one to four weeks.
- The people who care about the outcome will look at that increment when the sprint ends.
Planning fills the board, and the Daily Scrum checks progress against the sprint goal. Blocked cards need an owner. Unfinished cards leave when the sprint ends, because a board cluttered with leftovers hides how much actually finished.
The board stops working when the sprint is only a suggestion. If incidents and small fixes land every afternoon, you have a flow problem. Velocity ends up measuring interruptions while stakeholders still hear it described as a commitment.
Keep the sprint board small enough to close
Done means released, or ready to release under your definition of done. Split columns only where a handoff happens, for example In Progress, In Review, and Ready to ship. Cap In Progress below the headcount. Write the sprint goal in one sentence above the board. A card that doesn't serve the goal waits, even when it's small.
When a Kanban board fits
A Kanban board fits when work arrives unevenly and has to move within the current week. Support, on-call, and implementation teams work this way. A request that could be finished by Thursday shouldn't sit until Monday's planning.
On a Kanban board, the WIP limit does the job the calendar does in Scrum. If Building is capped at four and four cards are already there, the next move is to finish or unblock one of them. Starting a fifth is the failure. That pull rule is the core of Kanban flow: the board keeps moving because starting new work is treated as the expensive action.
Give urgent work its own class and its own cap. An expedite lane might allow one production incident in flight, and standard work pauses only for that slot. If urgent work has no cap, every card ends up urgent.
Column sets from software and operations teams are in 12 Kanban Board Examples From Real Software and Ops Teams. Copy a shape that matches your handoffs, then set limits tight enough that you'll actually hit them.
Pull from Ready
Someone takes the top card in Ready when they have capacity. Pre-assigning the next ten days of work recreates a sprint without the review at the end. Keep Ready ranked and replenish it when it runs low. In standup, discuss the oldest card first. If nobody ever reorders Ready, shrink its limit and name the person who decides what comes next.
Scrum and kanban boards on the same team
A feature squad can run a Scrum board while support stays on a Kanban board. What doesn't work is asking the same people to own a sprint goal and an unlimited interrupt queue. One of those promises will break, and it's usually the sprint.
Scrum and kanban boards inside one tool still need two separate policies. A "this sprint" filter only means something when cards outside it are genuinely optional. Switching methods later is a policy change: keep the columns, then add or remove the timebox, the goal, and the rule for new cards. Write down which requests may interrupt a sprint, who accepts them, and what gets paused. Without that note, whoever asks loudest wins.
A worked example: one week, two boards
Northwind ships billing software. (This is an illustration, not a benchmark.) Its eight engineers are split into a feature squad and a support squad.
Feature squad, Scrum board. The squad runs a two-week sprint with the goal that customers can export invoices as CSV. There are six stories, and the columns are To Do, In Progress (limit 3), In Review (limit 2), and Done.
On day three, a salesperson asks for a PDF template. The request goes to the product backlog instead of this board. On day ten, one story is still in review, so it returns to the backlog. Five stories ship. The review shows the export running in production, and the missed story stays visible.
Support squad, Kanban board. The columns are Incoming, Ready (limit 8), Building (limit 3), Review (limit 2), and Done. The expedite lane allows one urgent card. On Monday a failed webhook qualifies, so someone pauses standard work to take it. The squad counts finished cards and how long standard cards took from Ready to Done, and compares those numbers only against its own queue.
Same company, same week. The scrum board vs kanban board difference here is the refusal rule. Feature work waits for the next sprint, and support work waits for a free slot. If the PDF request had gone onto the Scrum board because it was small, the sprint would have been lost while the ceremonies carried on.
Where a kanban board and scrum board usually live
A kanban board and scrum board can be tape on a wall, a spreadsheet, or a hosted tracker. The tool doesn't make the policy true. It makes the policy easier to see, or easier to ignore once the team grows.
Trello is a set of lists. It's quick for a simple Kanban board and gets awkward once a sprint has to close and you want cycle time. Trello Kanban Boards for Development Teams: Where They Work and Where They Break walks through where that line falls.
Jira can host a Scrum board with a sprint backlog, or a Kanban board with column limits and no sprint. How to Set Up a Jira Kanban Board (and When to Use Something Else) covers the setup and the point where the tool's structure outgrows the work.
Either policy can run on tickets you already trust. Falrow, in private beta, gives each ticket type its own stages and triage, and its cycles roll unfinished work forward only after a review. Those tickets can feed a roadmap and cycle-time percentiles. A whiteboard still works fine as long as the refusal rule is real. See how requests become shipped work and tickets, triage, and workflow rules. Either way, agree on the rule before you move any cards.
How to choose in one sitting
Answer four questions somewhere the whole team can see them, before anyone starts comparing software.
- Can we freeze most scope for one or two weeks? If not, use a Kanban board.
- Do stakeholders need a fixed meeting where they inspect a finished increment? If so, use a Scrum board, or a Kanban board plus a review people actually attend.
- Is the pain that too much is started at once, or that there's no shared goal? WIP limits fix the first and a sprint goal fixes the second. If you have both, run Scrum with hard column limits or Kanban with a weekly goal. Adding more columns fixes neither.
- Who may add a card today? If the honest answer is anyone, anytime, a Scrum board will be false by mid-sprint.
If the way work arrives changes next quarter, redraw the board. A year of sprint commitments nobody believed costs more, because people will ignore the next real commitment too.
What to measure
On a Scrum board, track whether the sprint goal was met and how many items finished. A smooth burndown alongside a missed goal means cards moved but the increment didn't ship. Don't count unfinished work as success.
On a Kanban board, track weekly throughput, cycle time, and the oldest card in each column. If half your cards finish quickly and a few sit for weeks, customers notice the few. Compare a team against its own recent history rather than another team's points. Treat that history as an input to planning, not a promise about work the team has never done.
Mistakes that make the board lie
The first mistake is silent carry. On a Scrum board, unfinished work calls for a decision: return it, cut it, or plan it again. If it carries over automatically, the sprint length is just decoration. The Kanban version of this mistake is raising WIP limits every time the board feels tight. It's supposed to feel tight.
The second is using one column for every kind of wait. Build, review, and deploy are separate queues, so split out the ones that fill up and give them limits. A Scrum board holds the sprint backlog, not the roadmap, and Ready on a Kanban board covers only a short horizon. Keep later ideas off the current columns.
The third is keeping old meetings after the rule changes. A team that drops sprints but keeps a two-hour planning session, without adding WIP limits, holds onto the ceremony and loses the constraint. Delete the meeting that served the old rule.
FAQ
Is a Scrum board the same as a Kanban board?
No. A Scrum board holds one sprint backlog and closes with the sprint. A Kanban board stays open and uses WIP limits so people finish work before starting more. The Scrum Guide defines the sprint and its events, while Kanban defines pull and limits. Matching columns don't make the two systems the same.
Can one team use scrum and kanban boards together?
Yes, as long as each board has its own policy and the same people aren't committed to both a sprint goal and an open interrupt queue. A common split is a Scrum board for planned product work and a Kanban board for production support, with a named limit on urgent items. A single board that claims to be both, with no rule for new cards, is just a backlog.
How many columns should a Scrum or Kanban board have?
Enough to show the real handoffs, and few enough that each column has a clear exit test. Three to six is typical, such as ready, in progress, review, and done. Add a column only when work regularly waits there. A column without a limit turns into storage.
Which board is better for a small software team?
The one that matches how your work arrives. Four people with a stable backlog and a review every two weeks usually do better with a Scrum board. Four people who fix customer issues the day they come in usually do better with a Kanban board and a WIP limit below the team size. Headcount doesn't decide it. What decides it is whether the team can say no until the next sprint.