Managing Scrum Boards in Jira: The Complete Guide
This skill teaches you how to set up and manage Jira scrum boards, configure custom workflows, track team velocity, and generate burndown charts to maintain full sprint visibility.
To manage a Jira scrum board, create a new Scrum board project, configure columns to match your team's workflow stages (To Do, In Progress, In Review, Done), add swimlanes for visibility, populate the backlog with user stories, plan sprints by dragging items into a sprint, then use the built-in velocity chart and burndown chart to track progress and forecast capacity.
Outcome: You'll have a fully configured Jira scrum board that gives your team clear sprint visibility, accurate velocity tracking, and actionable burndown data for continuous improvement.
Prerequisites
- Basic understanding of Scrum framework (sprints, backlog, ceremonies)
- Jira Cloud or Data Center account with project admin permissions
- Familiarity with user stories and story point estimation
Overview
A Jira scrum board is the operational nerve center for any team practicing Scrum. It translates the abstract framework of sprints, backlogs, and ceremonies into a concrete, interactive workspace where every team member can see what's in progress, what's blocked, and what's done. Without a well-configured board, teams lose visibility, sprint planning becomes guesswork, and retrospectives lack the data they need to drive real improvement.
Managing a Jira scrum board goes far beyond simply creating a project and dragging cards around. It means designing workflows that mirror how your team actually works, configuring columns and swimlanes so information is instantly scannable, and leveraging Jira's built-in reporting — velocity charts, burndown charts, sprint reports — to make data-driven decisions about capacity and scope. This skill bridges the gap between knowing Scrum theory and executing it with precision in your team's primary tool.
Whether you're a Scrum Master setting up a board for a new team, a product owner wanting better backlog visibility, or a developer who wants to understand the mechanics behind the board you use every day, mastering Jira scrum board management will make your sprints more transparent, predictable, and ultimately more productive.
How It Works
Jira scrum boards operate on a pull-based system built around sprints. The backlog serves as a prioritized queue of work items (user stories, bugs, tasks), and during sprint planning, the team pulls a subset of those items into a time-boxed sprint. The board then visualizes each item's journey through workflow states — typically columns like To Do, In Progress, In Review, and Done.
Under the hood, every column on the board maps to one or more workflow statuses. When a team member drags a card from one column to another, Jira transitions the underlying issue through its workflow. This is why workflow configuration matters so much: if your workflow doesn't reflect reality, the board becomes a lie. Teams that skip workflow customization end up with cards stuck in ambiguous states or, worse, moving cards without updating the actual status.
Jira's reporting engine reads these transitions to generate metrics. The burndown chart plots remaining work (in story points or issue count) against the sprint timeline, showing whether the team is on track. The velocity chart aggregates completed story points across sprints, giving the team and product owner a reliable baseline for future sprint planning and estimation. These reports are only as accurate as the board's configuration and the team's discipline in keeping cards updated.
Step-by-Step
Step 1: Create a Scrum Board Project
In Jira, go to Projects > Create Project and select the Scrum template. Name your project using a clear convention (e.g., "Mobile App — Sprint Team") and choose a meaningful project key (e.g., MOB). Select the team-managed or company-managed type depending on your organization's governance model.
Company-managed projects give Jira admins centralized control over workflows and permissions, which is ideal for larger organizations. Team-managed projects let individual teams customize their own boards without admin intervention, which works well for smaller, autonomous teams.
Once created, Jira automatically generates a scrum board with a backlog view and an active sprint board. You'll customize both in the following steps.
Tip: If your organization already has a Jira project but it's using a Kanban board, you can create a new Scrum board from the same project by going to Board > Create Board > Scrum Board and selecting the existing project as the source.
Step 2: Configure Your Workflow to Match Team Reality
Navigate to Board Settings > Columns to see the default column mapping. The default Scrum board typically has three columns: To Do, In Progress, and Done. Most teams need more granularity.
Add columns that reflect your actual process. A common configuration for a development team is: To Do → In Progress → Code Review → QA → Done. For each column, map the corresponding Jira workflow statuses. If needed, go to Project Settings > Workflows to add custom statuses first.
Set column constraints (WIP limits) to prevent bottlenecks. For example, if your team has 5 developers, setting an In Progress limit of 5-7 helps surface overcommitment. While Jira won't enforce hard WIP limits on Scrum boards the way it does for Kanban, the visual indicator flags violations during standups.
Tip: Keep your workflow under 6-7 columns. Every additional column increases cognitive overhead during daily standups and makes the board harder to scan at a glance.
Step 3: Set Up Swimlanes and Quick Filters
Swimlanes add horizontal groupings to your board. Go to Board Settings > Swimlanes and choose a grouping strategy. The most common options are:
- Stories (default): Groups sub-tasks under their parent story, which is great for seeing progress on individual features.
- Epics: Groups all issues by their parent epic, useful during larger initiatives.
- Assignees: Shows each team member's work in their own lane — helpful for spotting overloaded individuals during standups.
Next, set up Quick Filters under Board Settings > Quick Filters. Create JQL-based filters for common views:
type = Bugfor a bugs-only view,priority = Highestfor critical items, orlabels = blockedfor blocked items. These filters appear as toggle buttons above the board and let team members switch context instantly.Tip: Create a 'Flagged' quick filter using the JQL `flagged = impediment`. This surfaces flagged/blocked items immediately, which is invaluable during daily standups.
Step 4: Populate and Prioritize the Backlog
Switch to the Backlog view. This is where you and the product owner maintain the prioritized list of work. Create user stories, bugs, and tasks directly in the backlog. Each item should have:
- A clear summary ("As a [user], I want [goal] so that [reason]")
- Acceptance criteria in the description
- Story point estimates (added during estimation sessions)
- An epic assignment for higher-level tracking
- Appropriate labels and components for filtering
Drag items to reorder by priority — the top of the backlog represents the highest-priority work. During backlog grooming, the team refines items near the top to ensure they're sprint-ready. Items without estimates or clear acceptance criteria should be flagged and refined before they enter a sprint.
Tip: Use Jira's bulk edit feature to add story points, labels, or epic links to multiple issues at once. Select issues with checkboxes, then use the context menu to batch-edit.
Step 5: Plan and Start a Sprint
In the Backlog view, you'll see a section at the top labeled with your next sprint. Drag items from the backlog into this sprint container. Jira will display the total story points being committed, which you should compare against your team's velocity from previous sprints.
Set a sprint name that's meaningful (e.g., "Sprint 14 — Checkout Flow"), a start date, an end date (typically 1-2 weeks), and a sprint goal that summarizes the sprint's primary objective. The sprint goal is critical — it gives the team a shared focus and provides context during daily standups and sprint reviews.
Click Start Sprint to activate it. The board view will now show only the items committed to the active sprint, and the burndown chart begins tracking from this moment.
Tip: Never start a sprint without a sprint goal. If you can't articulate what the sprint is trying to achieve in one sentence, the scope likely needs tightening.
Step 6: Monitor Progress with Burndown and Velocity Charts
During the sprint, navigate to Reports from the left sidebar. The two most critical reports for Jira scrum board management are:
Burndown Chart: Shows remaining work (story points or issue count) plotted against the sprint timeline. The ideal trend line slopes downward from total committed points to zero by sprint end. If your actual line is above the ideal line, the team is behind. If scope was added mid-sprint, you'll see upward spikes — these are valuable data points for retrospectives.
Velocity Chart: Displays committed vs. completed story points across the last several sprints. This is your team's most reliable planning input. If you've consistently completed 30-35 points per sprint, committing to 50 next sprint is unrealistic. Share velocity data with the product owner to set expectations during sprint planning.
Review the burndown chart daily (ideally during standup) and the velocity chart at the end of each sprint during retrospectives.
Tip: If your burndown chart is flat for the first few days of every sprint and then drops sharply near the end, your team may be working on large stories that don't get marked done until late. Break stories into smaller slices to get smoother burndown curves.
Step 7: Complete the Sprint and Handle Unfinished Work
When the sprint end date arrives, go to the active sprint board and click Complete Sprint. Jira will present a summary showing completed issues and any incomplete items. For each incomplete item, you have three options:
- Move to the next sprint: The item carries over and counts against the next sprint's capacity. This is appropriate for items that are partially done.
- Move to the backlog: The item goes back to the backlog for re-prioritization. Use this for items that were de-scoped or are no longer urgent.
- Leave in the current sprint: Rarely used, but keeps the item associated with the closed sprint for reporting purposes.
After completing the sprint, review the Sprint Report under Reports > Sprint Report. This report shows the full picture: what was committed, what was completed, what was added mid-sprint, and what was removed. This data is essential input for your sprint retrospective.
Tip: Track your sprint completion rate (completed points / committed points) over time. A healthy team consistently completes 80-100% of committed work. If you're regularly below 70%, you're overcommitting — use velocity data to right-size your sprints.
Examples
Example: Setting Up a Jira Scrum Board for a New Mobile Development Team
A newly formed mobile development team of 6 (4 developers, 1 QA engineer, 1 designer) is starting their first sprint. They need a Jira scrum board configured for their specific workflow, which includes design handoff, development, code review, QA testing, and release staging.
The Scrum Master creates a new Scrum project called 'Mobile App v2' (key: MAV2). In Board Settings > Columns, they replace the default three columns with six: Backlog → Design Review → In Development → Code Review → QA → Ready for Release → Done. They map the corresponding workflow statuses to each column.
For swimlanes, they choose 'Epics' since the team is working across three major epics: Onboarding, Payments, and Notifications. They create Quick Filters for type = Bug, assignee = currentUser(), and flagged = impediment.
The product owner populates the backlog with 45 user stories across the three epics, each with acceptance criteria and story point estimates from a planning poker session. For Sprint 1, the team commits to 28 story points based on comparable team velocities in the organization.
During the sprint, the team reviews the burndown chart at each standup. By day 3, the burndown shows they're slightly behind the ideal line. The board reveals three items stuck in Code Review — a bottleneck caused by only one senior developer doing reviews. They adjust by pairing junior developers for reviews, clearing the bottleneck by day 5.
At sprint end, they complete 24 of 28 points (86% completion rate). The remaining 4-point story moves to Sprint 2. The Sprint Report shows no mid-sprint scope additions, confirming good discipline. They use this data in their retrospective to discuss the code review bottleneck and decide to implement a review rotation policy.
Example: Using Velocity Data to Improve Sprint Planning Accuracy
A team has been running sprints for 8 weeks (4 two-week sprints) but consistently overcommits, completing only 60-70% of planned work. The product owner is frustrated because delivery forecasts keep slipping.
The Scrum Master pulls up the Velocity Chart from the Jira scrum board reports. The data shows:
- Sprint 1: Committed 40 pts, Completed 28 pts
- Sprint 2: Committed 42 pts, Completed 30 pts
- Sprint 3: Committed 38 pts, Completed 25 pts
- Sprint 4: Committed 35 pts, Completed 26 pts
The average velocity is 27.25 points, but the team has been committing 35-42 points. The Scrum Master presents this chart at the Sprint 5 planning session and proposes committing to no more than 28 points — the rolling average rounded slightly up for aspirational stretch.
For Sprint 5, the team commits to 27 points. They also examine why completed velocity is low: the Sprint Reports reveal that 3-5 points of unplanned bug fixes get added each sprint. They create a 5-point buffer in future sprint plans for incoming bugs.
Sprint 5 results: Committed 27 pts, Completed 29 pts (including 4 points of mid-sprint bugs). The team completes everything committed for the first time, and the product owner can confidently forecast delivery timelines based on the ~28-point sustainable velocity.
Best Practices
Update card statuses in real time, not in batches at end-of-day. The board is only useful if it reflects current reality — stale boards erode trust and make standups performative.
Keep your Jira scrum board columns to 5-7 maximum. Each column should represent a genuinely distinct workflow state where work can accumulate or get blocked. If two columns always have the same cards, merge them.
Use epics and labels consistently across the backlog so Quick Filters and swimlanes actually work. Establish naming conventions early and enforce them during backlog grooming sessions.
Review velocity trends over at least 3-4 sprints before using them for capacity planning. A single sprint's velocity is noise; the rolling average is the signal.
Set Definition of Done criteria at the board level (documented in the sprint description or a pinned Confluence page) so every team member knows what 'Done' means when moving a card to the final column.
Archive completed sprints regularly and clean up unused components, labels, and fix versions to prevent Jira from becoming a cluttered graveyard that slows down searches and reporting.
Common Mistakes
Creating a Jira scrum board with default columns and never customizing the workflow
Correction
Spend 30 minutes with your team mapping your actual process to board columns before the first sprint. A To Do → In Progress → Done board hides critical workflow stages like code review and QA where work frequently stalls.
Adding scope mid-sprint without tracking it, then blaming the team for not finishing everything
Correction
When scope is added mid-sprint, Jira's burndown chart captures it as an upward spike. Use these spikes in retrospectives to quantify scope creep. If mid-sprint additions are frequent, address the root cause with the product owner rather than absorbing the chaos.
Using issue count instead of story points for burndown charts, leading to misleading progress signals
Correction
Switch your burndown chart to story points (Board Settings > Estimation > Story Points). A sprint with 10 issues might have one 13-point epic and nine 1-point tasks — completing the small tasks first shows 90% progress by count but only 30% by effort.
Treating the Jira board as a project management surveillance tool rather than a team collaboration tool
Correction
The board exists to help the team self-organize and make impediments visible. If team members are anxious about card movements being monitored, the board becomes a source of stress rather than transparency. Focus board reviews on flow and blockers, not individual performance.
Never closing or completing sprints, letting them run indefinitely with accumulating work items
Correction
Complete every sprint on its scheduled end date, even if work is unfinished. Incomplete items move to the next sprint or back to the backlog. Velocity and burndown charts are meaningless without clean sprint boundaries.
Other Skills in This Method
Defining Scrum Roles and Accountabilities
How to clearly establish and operate within the Product Owner, Scrum Master, and Development Team roles as defined by the Scrum framework.
Facilitating Sprint Retrospectives
How to lead retrospective meetings that surface actionable improvements and foster a culture of continuous team learning.
Grooming and Refining the Product Backlog
How to continuously prioritize, estimate, and refine backlog items so they are sprint-ready with clear acceptance criteria.
Planning and Executing Sprints
How to scope, plan, and run time-boxed sprints including backlog selection, capacity planning, and sprint goal setting.
Estimating Work with Story Points and Planning Poker
How to use relative estimation techniques like story points and planning poker to forecast sprint capacity and improve predictability.
Running Effective Daily Stand-Up Meetings
How to facilitate focused, time-boxed daily scrum meetings that surface blockers and align the team on sprint goals.
Conducting Sprint Reviews and Demos
How to run effective sprint review meetings that demonstrate working increments to stakeholders and gather actionable feedback.
Frequently Asked Questions
What is the difference between a Jira scrum board and a Kanban board?
A Jira scrum board organizes work into time-boxed sprints with a defined start and end date, a backlog, and sprint-specific reports like burndown charts. A Kanban board uses continuous flow without sprints, focusing on WIP limits and cycle time. Choose Scrum when your team needs structured iteration cadences; choose Kanban for ongoing support or maintenance work.
How do I add a burndown chart to my Jira scrum board?
Burndown charts are built into every Jira scrum board automatically. Navigate to your board, click 'Reports' in the left sidebar, and select 'Burndown Chart.' It will display data for your active or most recently completed sprint. Ensure your estimation statistic is set to Story Points under Board Settings > Estimation for the most accurate chart.
Can multiple teams share the same Jira scrum board?
Technically yes, but it's not recommended. Each team should have its own scrum board with its own backlog and velocity tracking. If multiple teams work in the same Jira project, create separate boards using board-level JQL filters (e.g., filtering by team label or component). Shared boards make velocity meaningless and sprint planning chaotic.
How many story points should I commit to in a Jira scrum sprint?
Use your team's velocity chart as the guide. Look at the average completed story points over the last 3-5 sprints and commit to that average or slightly below. Never use committed points as the baseline — use completed points. If you're a new team without history, start conservatively and let 3-4 sprints establish your baseline.
How do I handle bugs found during a sprint on the Jira scrum board?
If the bug is related to work in the current sprint, add it to the active sprint and link it to the parent story. If it's unrelated, add it to the backlog for prioritization in the next sprint. Track mid-sprint additions in your burndown chart to quantify disruption, and discuss recurring patterns during sprint retrospectives.
What Jira scrum board reports should I review during a sprint retrospective?
Review three reports: the Sprint Report (shows committed vs. completed work, plus scope changes), the Burndown Chart (reveals daily progress patterns and scope creep spikes), and the Velocity Chart (shows multi-sprint trends). Together, these give your retrospective concrete data instead of just opinions about what went well or poorly.