Jira scrum vs kanban board: what's the difference?

The short answer

A scrum board works in sprints. The team picks a set of work for a fixed period, starts the sprint, and the board shows only that sprint's work. When the sprint ends, the team completes it and plans the next one.

A kanban board has no sprints. Work flows onto the board whenever there is room, moves from left to right, and leaves when it is done. Instead of planning in fixed periods, the team limits how much work is in progress at the same time.

Day to day, you use both the same way: open tickets, move your cards, comment. What changes is where new work waits, when it appears on the board, and what happens to finished work.

Side by side

The sections below explain each row and how it looks in Jira.

How to tell which board you have

Look at the board and the navigation around it:

• You see a sprint name and dates above the board, an Active sprints view, or Start sprint and Complete sprint buttons. That is a scrum board, or a board with the sprints feature turned on.
• You see no sprint at all, and new work appears straight in the first column. That is a kanban board.
• You see a Backlog tab with sprint sections (one block per sprint, then a block called Backlog). That is scrum. A kanban board can also have a backlog, but it has no sprint sections in it.

In Jira Cloud the line between the two is less strict than it used to be. Atlassian's help pages describe the backlog and sprints as features a board can have switched on or off, so a board created from the kanban template can end up with a backlog, and the template name matters less than what is switched on. When you create a software space, Atlassian offers scrum, kanban and bug tracking templates.

How a scrum board works in Jira

Scrum comes from the Scrum Guide, which describes sprints as fixed-length events of one month or less, with a new sprint starting immediately after the previous one ends. Each sprint has a single objective, the Sprint Goal. In Jira, a sprint runs like this:

1. Plan. On the Backlog tab, the backlog shows the space's work items grouped into a backlog and sprints. The team drags work from the Backlog section into the sprint section.
2. Start. Someone selects Start sprint, sets the sprint name, the start and end dates and, if they want, a Sprint goal, then selects Start. Jira opens the Active sprints page with the sprint's work.
3. Work. During the sprint, the board shows that sprint's work. Everyone moves their cards from column to column as work progresses.
4. Complete. At the end, someone selects Complete sprint. Atlassian's help says a work item counts as complete once it is in the last column on the board. Anything unfinished goes to the backlog, a future sprint, or a new sprint.

The practical effect for you: on a scrum board, a ticket that sits in the backlog is not on the board until someone adds it to the active sprint. If you created a ticket and cannot find it on the board, look in the backlog first. The full sprint lifecycle is covered in what a sprint is in Jira, and the difference between the two lists in backlog vs sprint.

How a kanban board works in Jira

The Kanban Guide describes kanban as a strategy for optimizing the flow of value through a process. It asks the team to visualize its workflow, to control the number of items in progress explicitly, and to keep improving the flow. It does not prescribe sprints.

In Jira, that shows up in three places:

• Column limits. A company-managed board can set a minimum and maximum number of work items per column. Jira shows a red column header when the maximum is exceeded and a yellow one when the minimum is not met. The limits are warnings only: Jira still shows every card.
• Finished work drops off. Atlassian's board help says that on a board without sprints, work items in Done are removed from the board automatically after 14 days. Company-managed kanban boards have a setting for this with options of 1, 2 or 4 weeks, or no limit.
• The backlog is optional. Atlassian notes that teams working in a kanban style traditionally do not use a backlog, but they can turn one on to hold work they have not started.

The Kanban Guide also defines four flow measures a kanban team can track: work in progress (started but not finished), throughput (finished per unit of time), work item age (time since it started) and cycle time (time from start to finish).

What changes for you day to day

Less than you might think. On both boards you:

• move a card to the next column when you start or finish something;
• comment on a ticket when you move it, so the team knows what happened;
• open the ticket before asking for an update, since the latest comment may already answer you.

The differences that matter in practice:

• On a scrum board, pulling new work mid-sprint is a team decision, because it changes what the team committed to. If something urgent comes in, raise it with whoever runs the sprint rather than dragging it in quietly.
• On a kanban board, the column limits are the signal. If In Progress is already at its limit, finishing or unblocking something comes before starting something new.

If you are choosing one

If you are setting up a board for your own team, ask how the work arrives. A team that can plan a few weeks ahead and wants to review its progress together at fixed points may find sprints useful. A team that handles a steady stream of requests that cannot wait for the next planning session, such as support or operations work, may find a continuous flow with column limits easier. Neither is more advanced than the other, and the basics of reading and moving tickets are the same on both (see the beginner's guide).

Practise on a sprint board

The easiest way to get a feel for a board is to work on one. Agile Board Practice puts you on a practice sprint board with To do, In progress, In review and Done columns, where you read the board, move your own work, and run a busy board near the end of a sprint, with feedback on every step.