Managing Scrum Boards in Jira: Setup, Sprints, Reports

Set up a Jira scrum board, map columns, run sprints and read the burndown and velocity charts, following Atlassian's own documentation.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

A Jira scrum board is Atlassian's tool for holding a team's backlog, running sprints and reporting on them. Atlassian's Learn scrum with Jira tutorial walks through the basic flow: create work items in the backlog, rank them by dragging, create a sprint, drag the agreed items into it, start it, and work from the Active sprints view. Reports such as the Burndown Chart and Velocity Chart are built from the board's data. This skill covers managing scrum in Jira from setup through sprint completion, as Atlassian documents it for Jira Cloud.

Jira's terms differ from Scrum's in places. Recent Atlassian documentation calls projects "spaces" and issues "work items." A Jira sprint maps to a Scrum Sprint. The Jira backlog holds the Product Backlog, and the items dragged into a sprint plus any subtasks approximate the Sprint Backlog; the Sprint Goal can be entered when the sprint is started. Some features, such as creating extra boards, differ between company-managed and team-managed spaces, and the steps below follow the company-managed documentation.

The board is a way to make the Scrum artifacts transparent, and its settings shape what the reports say. Atlassian's documentation for the velocity chart and burndown chart both say the reports are board-specific and based on the board's column mapping: a work item counts as Done only when it is in a status mapped to the right-most column. A board with wrong column mapping produces misleading charts, so configuration comes before reporting.

The Scrum Guide says practices such as burn-downs and burn-ups "do not replace the importance of empiricism." Use the charts to start conversations in the Daily Scrum, Sprint Review and retrospective. For Scrum itself, see the Scrum method page.

How It Works

A scrum board is defined by a saved filter. When you create a scrum board based on one or more existing spaces, Jira builds a pre-configured board containing all the work items in those spaces, using a work item filter written in JQL. Everything the board and its reports show comes from that filter. Atlassian notes that team-managed spaces do not support creating additional boards directly, and that a board can be created from a saved filter instead.

Columns are mapped to workflow statuses. Atlassian's column configuration guide says Jira only considers work items in the right-most column as complete, and that statuses representing completed work should be mapped there, or a sprint may not complete cleanly. Columns can have minimum and maximum constraints; when a maximum is exceeded the column header turns red, and when a minimum is not met it turns yellow. For Scrum teams, Atlassian recommends counting work items excluding subtasks, so the limit applies to stories.

Swimlanes and quick filters change what people see without changing the data. Swimlanes can be based on queries, stories, assignees, epics or spaces, or turned off. Query-based swimlanes start with an "Expedite" lane for blocker priority and an "Everything Else" lane that catches the rest. Quick filters narrow the board, with two defaults: only the viewer's work items, and items updated in the last 24 hours. Atlassian notes that the new board view renames quick filters to custom filters.

The reports read the board's estimation statistic. The velocity chart can use story points, original time estimates or any numeric custom field. For each sprint it shows a gray commitment bar, the total estimate when the sprint began, and a green completed bar, the total completed when it ended, plus an average line. Atlassian says estimates on subtasks are not included in the velocity chart or in the burndown's story points. The burndown chart shows the work remaining in a sprint over time against a guideline, and marks scope changes.

Sprints end through a deliberate step. According to Atlassian's page on how to complete a sprint, you need to be a Jira administrator or have the Manage Sprints permission, all subtasks must be Done, and any incomplete parent work items are moved to the backlog, a future sprint, or a new sprint. That choice is where Jira meets the Scrum rule that unfinished work returns to the Product Backlog.

Step-by-Step Guide

Step 1: Create the Jira scrum board

Following Atlassian's create a board steps, go to all boards, select Create board, and choose Create a Scrum board. Base it on a new software space or on one or more existing spaces; both require the Browse spaces permission. If your team works in a team-managed space that does not allow extra boards, create the board from a saved filter instead. Share the board link with the team once it exists.

Step 2: Check the board filter

Open the board settings and read the filter query. Make sure it includes every work type and status the team works with, and nothing it does not. Atlassian's troubleshooting advice for missing items is to check the filter, the column mapping and whether the backlog is enabled. Keep the filter simple: Atlassian's complete a sprint page notes that when a filter is complex, Jira may be unable to determine which spaces it returns, and the sprint may not complete.

Step 3: Map columns to the team's workflow

Create columns for the stages work actually passes through, such as To Do, In Progress, In Review and Done, and map each status to one column. Put every status that means the work is finished in the right-most column, as the column configuration guide instructs. Align that column with the team's Definition of Done, so "Done" in Jira means Done in Scrum. Add column constraints if the team wants to limit work in progress, counting items without subtasks.

Step 4: Configure swimlanes and quick filters

Choose a swimlane method that helps the Daily Scrum. Grouping by stories keeps subtasks under their parent, and query-based lanes can separate expedited work. Add quick filters for views the team uses often, such as one per component or one for blocked items, written in JQL. Keep the number small so the board stays readable.

Step 5: Build and rank the backlog

Create work items in the backlog and rank them by dragging, as described in Atlassian's scrum tutorial. The Product Owner owns the order. Add descriptions and acceptance criteria during refinement, and enter the Developers' estimates in the story points field. Keep the top of the backlog refined and sized ahead of Sprint Planning.

Step 6: Plan and start the sprint

Create a sprint in the backlog. During Sprint Planning, drag the items the team selects into it, and break them into subtasks if that helps the Developers plan. When you start the sprint, name it, set its duration and dates, and enter the Sprint Goal the team agreed. The team then works from Active sprints, moving items across the columns as they progress.

Step 7: Read the Jira burndown chart during the sprint

In the Daily Scrum, look at the burndown chart to see whether remaining work is trending toward the Sprint Goal. Atlassian's tutorial lists patterns worth discussing: a team that finishes early every sprint, one that misses its forecast every sprint, and steep drops that suggest work was not broken down finely enough. If the guideline is missing, the sprint may have been started before any items were added. Treat what the chart shows as a prompt for discussion.

Step 8: Complete the sprint and check the Jira velocity chart

After the Sprint Review, complete the sprint. Make sure subtasks are Done, then choose where incomplete work items go; moving them to the backlog lets the Product Owner reorder them, which matches Scrum. Open the velocity chart before the next planning and compare commitment with completed across recent sprints. Use the spread as a forecast range for the next Sprint Planning.

Best Practices

• Configure columns before trusting reports. Both charts read the right-most column as Done, as Atlassian's velocity documentation states, so a wrong mapping silently distorts them.
• Match Jira's Done to the Definition of Done. A status that means "code merged" when the Definition of Done requires testing and release creates two versions of Done.
• Estimate parent items. Atlassian notes that subtask estimates are excluded from velocity and from story points in the burndown, so size the story itself.
• Enter the Sprint Goal when starting the sprint. It keeps the goal visible on the board, where the Developers look every day.
• Move unfinished work to the backlog by default. Carrying it straight into the next sprint skips the Product Owner's reordering decision that the Scrum Guide calls for.
• Keep the board lean. A few swimlanes and quick filters that people use beat a board nobody can read.

Common Mistakes

• Leaving Done-like statuses out of the right-most column: Items in "Released" or "Closed" columns count as incomplete, which breaks charts and can block sprint completion. Map every finished status to the right-most column.
• Adding work after the sprint starts without discussing it: Atlassian notes that items added after a sprint starts are left out of the velocity chart's commitment bar, so the chart and the plan drift apart. Negotiate changes with the Product Owner so the Sprint Goal stays intact.
• Comparing velocity charts across teams: Each board has its own estimates and filter, so the numbers are not comparable. Use each chart only for its own team's forecasting.
• Treating the board as the Scrum: A well-configured board with no Sprint Goal, review or retrospective is a task tracker. Keep the Scrum events and use the board to support them.
• Overloading the board filter: A filter that spans many spaces and conditions makes items disappear and sprints hard to complete. Keep one board per team with a simple filter.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Scrum

Related Skills

• Scrum Sprint Planning: Planning and Executing Sprints
• Scrum Estimation with Story Points and Planning Poker
• Backlog Grooming and Product Backlog Refinement
• Running the Scrum Daily Standup (Daily Scrum)
• Conducting Sprint Reviews: Run the Sprint Review Meeting
• Facilitating Sprint Retrospectives for Scrum Teams
• Defining Scrum Roles and Accountabilities

Sources

• Atlassian: Learn scrum with Jira
• Atlassian Support: Create a scrum board
• Atlassian Support: Configure columns
• Atlassian Support: Configure swimlanes
• Atlassian Support: Configure quick filters
• Atlassian Support: Burndown chart
• Atlassian Support: Velocity chart
• Atlassian Support: Complete a sprint
• The Scrum Guide

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.