Jira Scrum Board: Columns Your Team Will Actually Follow

A Jira scrum board is not a whiteboard with columns drawn on it. It is a backlog, one or more sprints, and a set of columns that are bound to workflow statuses. That binding is the single fact that explains why some boards run for years and others quietly fill up with cards parked in the wrong place.

Most teams asking about scrum boards in Jira have already made one. The question underneath is usually narrower: which columns should exist, who is allowed to change them, and whether the ceremony around the board is worth the time it costs. This article covers how the board is assembled, how to choose a column set that survives contact with real work, what the plans include as of September 2026, and how to tell whether the weight belongs to Jira or to the configuration.

What a scrum board is made of

Three things stack up, and knowing which one to edit removes most of the confusion.

The backlog holds every potential work item for the space. It is ordered, and the order is the plan. Nothing in the backlog is committed to a date.

A sprint is a fixed period in which the team completes a chosen set of items. Sprints are created from the backlog view, items are dragged into them, and a sprint is started when planning is finished. Multiple sprints can be planned in advance from the same screen, and the order they sit in is the order they are meant to run, so reordering them is how a plan gets changed.

Columns are the part people argue about. Each column maps to one or more workflow statuses. Dragging a card from In Progress to In Review performs the status transition on the work item. It is not a cosmetic move. It is exactly the same operation as editing the status field on the item itself, which is why a column is never just a label. Adding one means either mapping a status that already exists or creating one for it.

Atlassian's own description of the model is direct about the relationship:

A Jira board is a visual tool or view used to manage work items as they move from creation to completion, shown as cards that move across columns. Source: atlassian.com

The word view is doing the work in that sentence. The cards are not stored on the board. The board is a way of looking at items that exist independently of it, which is why the same item can appear on a team board and a release board at once without being duplicated.

Scrum board or kanban board

Jira offers both, pre-configured. The difference is not visual, it is about what the team commits to.

A scrum board assumes work is committed in batches. There is a backlog, a sprint boundary, and a moment where the team says this much and no more. The board shows the current sprint, and the backlog is a separate screen. A kanban board assumes work arrives continuously. There is no sprint boundary, and the board shows everything in flight with limits on how much can sit in each column.

The practical test is whether a fixed commitment is useful. If work arrives from support, incidents or sales at an unpredictable rate, a sprint boundary becomes a fiction that gets broken every week, and breaking it repeatedly teaches the team that the commitment means nothing. If work is mostly generated inside the team and can be sequenced, the sprint boundary earns its keep because it forces prioritisation to happen at a known moment rather than continuously.

Teams often start with one and change later. Changing the board type is not a migration, because the underlying items are unaffected.

Choosing columns that survive

The default column set is To Do, In Progress and Done. It is boring and it usually holds. The failures start when columns are added, and there are three recurring ones.

A column for Blocked

Blocked is not a stage in the process. It is a condition that can apply to work at any stage. Making it a column means a blocked item loses the information about where it actually was, and when it unblocks somebody has to remember where to put it back. A flag on the card or a swimlane holds the same information without destroying the position.

A column per person

Boards with columns named after people stop being a picture of the process and become a picture of the team's org chart. When somebody is away, their column freezes and the work stops rather than being picked up. Swimlanes exist for this. Atlassian describes a swimlane as a horizontal categorisation of work in the active sprint, which is precisely the right shape for grouping by person, workstream or area.

A column that only one role can move out of

A review column is the usual case. If only two people can move items out of In Review, that column is a queue with a named bottleneck, and it will be the longest column on the board every week. The column is not wrong, but it needs a work in progress limit so the queue is visible rather than just long. Atlassian describes those limits as capping how many cards can sit in a column at once, which is what turns a bottleneck into something the team can see.

The useful rule is that a column should represent a change in who is holding the work, not a change in how the work feels. In Progress to In Review is a handover. In Progress to Almost Done is a mood.

Four or five columns is where most teams land. Past six, cards start skipping columns, and a skipped column is worse than no column because reports are built on the transitions.

Who can change the board

This is where the answer stops being about scrum and starts being about which kind of space the board belongs to.

A team-managed space owns its own workflow, fields and permissions. The person administering that space can add a status, map it to a new column, and be finished in a few minutes. Nothing outside the space is affected.

A company-managed space draws its configuration from shared schemes. The workflow may be used by several other spaces, so adding a status is a change to a shared object and normally goes through a Jira administrator. Company-managed spaces also allow several boards in one space and boards that pull items across spaces, which is why larger organisations use them.

	Team-managed	Company-managed
Who changes the workflow	The space admin	A Jira administrator
Effect of adding a status	Limited to that space	May affect other spaces sharing the scheme
Multiple boards in one space	Not available	Available
Boards spanning several spaces	Not available	Available
Time to add a column	Minutes	However long the request takes

Teams of five to thirty are almost always better served by team-managed, and a large share of complaints about Jira being slow to change turn out to be complaints about being in a company-managed space without needing to be. Checking which one the board lives in takes a moment and sometimes answers the whole question.

The ceremony the board assumes

A scrum board makes more sense when the events around it are the ones the Scrum Guide actually defines, because the board's screens are shaped to them.

The Guide sets sprints as fixed length events of one month or less, with a new sprint starting immediately after the previous one ends. Sprint Planning is timeboxed to a maximum of eight hours for a one-month sprint and is usually shorter for shorter sprints. The Daily Scrum is a 15-minute event for the developers on the team, held at the same time and place every working day. The Sprint Review is timeboxed to a maximum of four hours for a one-month sprint.

Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. Source: scrumguides.org

Atlassian's own board guide gives two weeks as its example of a regular, fixed length sprint cadence, which is where most teams of this size end up. Scaled in proportion, a two week sprint puts planning at around four hours and the review at around two. The Guide does not print those numbers, it only says shorter sprints usually have shorter events, but the proportional figure is the one worth holding against the calendar before committing to a cadence.

The board handles the sprint boundary directly. Completing a sprint moves all completed items out of the active sprint, and for the unfinished ones it offers the backlog, any future sprint that already exists, or a new sprint created on the spot. That prompt is the most useful moment in the whole cycle, because the number of items being moved is the honest measure of how good the last commitment was. A team that moves nine items every fortnight is not failing at Jira. It is committing to too much.

What the plans include

Prices below were read from Atlassian's own Jira pricing page on 27 September 2026, with monthly billing selected and tax excluded. That page serves the currency of the country it is opened from, and these figures were served in Japanese yen. Plan contents change, so this is a snapshot.

Plan	Price per user per month	What the page lists
Free	Free forever for 10 users	Backlog, list, board, timeline, calendar and summary views, reports and dashboards, 2 GB of storage, support from the Atlassian Community
Standard	1,085 yen	250 GB of storage, 9/5 regional support, up to 100,000 users per site
Premium	1,987 yen	Cross-team planning and dependency management, unlimited storage, 24/7 support for critical issues
Enterprise	Quoted	Annual billing only, advanced admin controls, multiple sites

The important point for a small team is that the scrum board itself is not the thing the paid tiers gate. Board, backlog, sprints and reports are present in the free tier. What changes further up is administration, capacity across multiple teams, support response and storage. A team of eight running one board has little reason to move up on board features alone.

The cost that is harder to see sits in the other direction. If the team is nine people and three of them only ever read the board, those three still occupy seats. Checking how a given tool counts read-only participants before comparing headline prices is worth the five minutes, and tools differ on it. A tool that does not count view-only guests changes the arithmetic for a team with stakeholders attached. How that line is drawn here is stated on pricing, and the differences item by item are set out in the comparisons.

When the weight is the tool and when it is the setup

The honest test is whether the friction disappears when the configuration changes.

If adding a column takes a week because a ticket has to go to an administrator, that is the space type, and moving to a team-managed space fixes it. If cards are stale because nobody updates them, that is not Jira, and no tool fixes it. If half the team cannot find the backlog, that is training. If the fields on the create screen ask for six things a designer cannot answer, that is the screen configuration, and it is editable.

What is genuinely structural is the shape of the model. Columns are statuses, statuses belong to workflows, and workflows may be shared. That is excellent for an organisation that needs consistency across many teams and permanent identifiers that survive reorganisation. It is heavier than a small team needs if the only requirement is one board, a timeline and a place to talk about the work. Teams in that second position often want the board and the schedule in the same place without a tier change, which is what features lists, and the differences against a board-first tool are laid out in the Trello comparison.

What to change first

Before rebuilding the board, count the items moved forward at the end of the last three sprints. If the number is consistently above two or three, the problem is the size of the commitment, and no column arrangement will fix it. Then check whether the board sits in a team-managed space, because that single fact decides whether the team can change its own columns this week or has to file a request. If the answer to both is uncomfortable, running one real sprint on a board where the columns, the timeline and the discussion sit together, such as Pinateca, makes the comparison concrete rather than theoretical.

Q1. Is a Jira scrum board free?

Yes, within the free tier's limits. Atlassian lists Jira Free as free forever for 10 users with 2 GB of storage and Atlassian Community support, and the board, backlog, timeline and reports are included rather than gated. Past ten users the pricing page listed Standard at 1,085 yen per user per month and Premium at 1,987 yen with monthly billing, in the currency it serves to a visitor in Japan.

Q2. How do you add a column to a Jira scrum board?

A column maps to one or more workflow statuses, so the status has to exist before the column can. In a team-managed space the space administrator can create the status and map it in the board settings. In a company-managed space the workflow comes from a shared scheme, so the change goes through a Jira administrator and may affect other spaces using the same workflow.

Q3. What should happen to unfinished items when a sprint ends?

Completing the sprint moves finished items out of the active sprint and prompts for where the unfinished ones go: the backlog, a future sprint that already exists, or a new one. Sending them to the backlog is the more honest default, because it forces the item to be prioritised again rather than silently carried. The count of items moved is the clearest signal of whether the sprint was over-committed.

Q4. Should Blocked be a column on a scrum board?

Usually not. Blocked is a condition that can apply at any stage, so making it a column loses the information about where the work actually was and creates an argument about where to return it. A flag on the card or a swimlane records the same thing without moving the item out of its real position.

Q5. How long should a sprint be?

The Scrum Guide sets an upper bound of one month or less and requires the length to be fixed. Atlassian recommends two weeks in its own tutorial, which is long enough to finish something and short enough for regular feedback. The length matters less than keeping it constant, because velocity across sprints is meaningless if the sprints are different sizes.

Q6. What is the difference between a scrum board and a kanban board in Jira?

A scrum board assumes work is committed in fixed batches, so it has a backlog, a sprint boundary and a separate backlog screen. A kanban board assumes work arrives continuously, so it shows everything in flight with limits on how much can sit in each column. Switching between them does not affect the underlying work items.