Scrum Board vs Kanban Board: Columns, Rules and When to Use Each

A Scrum board is the Sprint Backlog made visible: the Sprint Goal at the top, the items the team selected for this Sprint, and the tasks under each item moving through columns such as To Do, In Progress and Done. It lives for one Sprint. When the Sprint ends, finished work leaves the board, unfinished work goes back to the Product Backlog, and the board starts empty for the next Sprint. A Kanban board looks similar but works differently: it shows the whole workflow continuously, never resets, and limits how many items each column may hold.

What the Scrum Guide says, and does not

The Scrum Guide never mentions a board. What it requires is a Sprint Backlog that is “a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint,” with “enough detail that they can inspect their progress in the Daily Scrum.” A board is simply the most common way to meet that requirement. It belongs to the Developers: the 2020 Scrum Guide↗ (opens in a new tab) calls the Sprint Backlog “a plan by and for the Developers.”

The format itself comes from agile practice. The Agile Alliance glossary↗ (opens in a new tab) describes the basic task board as three columns labeled “To Do”, “In Progress” and “Done”, updated most often during the daily meeting and “commonly ‘reset’ at the beginning of each iteration.” It dates the five-column variant to Mike Cohn in 2003.

Scrum board columns

There is no standard set, but most Scrum boards use some version of these, read left to right:

• Sprint Goal (a banner, not a column). One sentence the team checks every trade-off against.
• Backlog item. Each row starts with one Product Backlog item selected at Sprint Planning, in order. This is the classic “story” column.
• To Do. The tasks the Developers broke that item into, usually a day of work or less, not started yet.
• In Progress. Tasks someone is working on now. A name or initials on each card tells the team who to ask.
• Review or Test (optional). Add it only if review is a real step with a real queue. If nothing ever waits there, it is noise.
• Done. Tasks finished, and items that meet the Definition of Done. An item that does not meet it is not done, however many of its tasks are.

Some teams add a Blocked marker rather than a column, so a blocked task keeps its place and the Daily Scrum sees it immediately.

Scrum task board rules

1. Only the Sprint’s work goes on it. New requests go to the Product Backlog, not straight onto the board.
2. The Developers own it. They add tasks, split them and move them; nobody outside the team moves cards for them.
3. Update it before the Daily Scrum, so the 15 minutes are spent on the Sprint Goal rather than on catching the board up.
4. Change scope through the Product Owner. The Guide lets the Developers renegotiate scope with the Product Owner as they learn, as long as the Sprint Goal is not endangered.
5. Done means the Definition of Done. Work that does not meet it cannot be shown at the Sprint Review and goes back to the Product Backlog.
6. Reset at the end. Clear the board after the Retrospective and build the next one at Sprint Planning.

Scrum board vs kanban board

The two look alike on a wall. The differences are in what the board is for. The Agile Alliance’s kanban board entry↗ (opens in a new tab) puts the main one plainly: “unlike a task board, the kanban board is not ‘reset’ at the beginning of each iteration.”

• Lifespan. Scrum board: one Sprint, then cleared. Kanban board: permanent; items flow through it continuously.
• What limits the work. Scrum board: the Sprint selection; the team takes on what it forecasts it can finish. Kanban board: a limit on work in progress, often per column.
• Columns. Scrum board: usually simple task states for this Sprint. Kanban board: the states of the team’s whole workflow, each with an explicit policy for entering and leaving.
• Adding work. Scrum board: new work waits for the next Sprint unless the Product Owner and Developers renegotiate scope. Kanban board: new work can be pulled as soon as there is capacity.
• What you measure. Scrum board: progress toward the Sprint Goal, often with a burndown chart. Kanban board: flow; the Kanban Guide↗ (opens in a new tab) requires measures of work in progress, throughput, work item age and cycle time.
• Who it belongs to. Scrum board: the Developers. Kanban board: the members of the Kanban system, with no roles prescribed.

Those differences follow from the methods themselves. Kanban vs Scrum compares the methods; this page is only about the board.

When to use each

• Use a Scrum board when you run Sprints and want one view of this Sprint’s commitment that the team can read in the Daily Scrum.
• Use a kanban board when work arrives continuously, such as support, operations or client requests, and a two-week plan would not survive.
• Use both when a Scrum team also handles interrupts: the Sprint on a Scrum board, the unplanned work on a small kanban board beside it. What is Scrumban covers the merged version.

A scrum board template

Copy this into a document, a whiteboard or a board tool at Sprint Planning. One row per selected item, tasks in the columns, and the goal where nobody can miss it.

SPRINT 14   October 6 - October 17
SPRINT GOAL: Customers can change a booking without calling support.
DEFINITION OF DONE: reviewed, tested, deployed to staging, help page updated

ITEM (in order)          | TO DO               | IN PROGRESS        | DONE
-------------------------+---------------------+--------------------+------------------
1 Change booking date    | email confirmation  | API endpoint (AK)  | design
                         | help page           |                    |
2 Show change fee        | fee rules           | UI banner (JR)     |
3 Cancel within 24 hours | refund call         |                    |
                         | tests               |                    |
-------------------------+---------------------+--------------------+------------------
BLOCKED: refund call waits on payments team (raised Oct 8)
NOT IN THIS SPRINT: new requests go to the Product Backlog

END OF SPRINT: items meeting the Definition of Done -> Sprint Review
               anything else -> back to the Product Backlog; clear the board

A Scrum board on fenbs, honestly

fenbs has four fixed lanes, To Do, Next Up, In Progress and Completed. It has no sprints, no custom columns, no swimlanes, no WIP limits and no burndown chart, so it is not a Scrum board out of the box. A small team can still run a Sprint on it by agreeing what each lane means:

• To Do is the Product Backlog, ordered by priority from 1 to 10, where 1 is the most urgent.
• Next Up is this Sprint’s selection, moved there at Sprint Planning. In Progress is what someone is working on now.
• Completed means the task met your Definition of Done. Write the Definition of Done and the Sprint Goal on the Decisions and rules page, so people and every connected AI assistant read them before they start work.
• A category named after the Sprint, such as “Sprint 14”, lets you filter to it later. At the end, move unfinished tasks back to To Do; History keeps a record of every move and who made it.

What you lose is the item-and-task layout: each fenbs task is one card, and its plan holds the steps rather than separate sub-cards. If your team needs task breakdowns as cards, a burndown chart or Sprint reports, use a dedicated Scrum tool.