Setting up a Scrum board in JIRA involves creating a project, configuring your board type, adding issues to the backlog, and customizing the board layout to match your team’s workflow. JIRA provides both Scrum and Kanban board templates, but the Scrum setup requires additional configuration for sprints, velocity tracking, and release planning. The process typically takes 15-30 minutes for a basic setup, though optimizing it for your team’s specific needs may require more time.
For example, a team managing a website redesign project might create a Scrum board with columns for Backlog, To Do, In Progress, Code Review, and Done, with each user story linked to specific sprint cycles. Beyond the initial setup, you’ll need to define your team’s commitment level, sprint duration (usually one or two weeks), and how issues will be estimated using story points. JIRA’s flexibility means your first board configuration won’t be perfect—most teams refine their setup after running two or three sprints and identifying what information matters most for their workflow.
Table of Contents
- What Makes JIRA’s Scrum Board Different from Standard Kanban?
- The Critical Setup Steps You Can’t Skip
- Customizing Columns to Reflect Your Team’s Workflow
- Estimating Work with Story Points and Sprint Capacity
- Avoiding Sprint Overload and Managing Mid-Sprint Changes
- Using Burndown Charts to Track Daily Progress
- Scaling Your Scrum Setup as Your Team Grows
- Conclusion
- Frequently Asked Questions
What Makes JIRA’s Scrum Board Different from Standard Kanban?
jira offers two primary agile board types: Scrum and Kanban. The Scrum board is built around sprints, which are time-boxed iterations where your team commits to completing a specific set of work. This structure includes backlog management, sprint planning, velocity charts, and burndown graphs that help teams forecast how much work they can realistically complete.
Kanban boards, by contrast, are continuous-flow systems without sprints—work moves through columns as it progresses, which works better for teams with unpredictable workloads or support-heavy operations. For a development team building a new application feature, the Scrum approach means deciding upfront what will ship in the next two weeks, breaking it into tasks, and tracking progress daily. The Kanban approach would work better if your team constantly receives ad-hoc bug reports and production issues that can’t wait for a sprint cycle. Many teams find Scrum’s sprint structure provides better forecasting and team accountability, though the overhead of planning ceremonies (sprint planning, daily standups, reviews, retrospectives) adds roughly 5-7 hours per sprint for a typical six-person team.
The Critical Setup Steps You Can’t Skip
Creating a Scrum board starts with creating a JIRA project if you don’t already have one. From the JIRA dashboard, click “Create project,” select “Scrum,” and choose between a cloud or server installation (cloud is more common now that JIRA Server has been discontinued). You’ll then need to configure your project settings, including the team members, the board name, and the sprint duration. One limitation here is that JIRA’s default settings often include more columns and fields than a new team needs, which can create confusion about workflow stages.
Many teams spend time deleting unnecessary custom fields or hiding them from the board view after discovering they’re not used. Once your project exists, you must set up sprints before your board becomes fully functional. Navigate to the “Backlog” view and create your first sprint by clicking “Create sprint.” Decide on your sprint length—two weeks is the industry standard, but one-week sprints work better for teams in crisis-mode releases, and three-week sprints suit teams with longer-term planning horizons. A warning: if you don’t create at least one sprint, your board will show an empty backlog view, which frustrates teams trying to start their first planning session. After creating your sprint, drag issues from the general backlog into your sprint backlog to populate the iteration with work.
Customizing Columns to Reflect Your Team’s Workflow
By default, JIRA creates a Scrum board with columns matching common workflow stages, but your team’s actual process might differ. If your development process includes a code review stage before merging, you’ll want to add an “In Review” column between “In Progress” and “Done.” Similarly, teams using QA will want a “Testing” column. You customize these columns by opening the board settings and editing the workflow configuration.
For a web design team using JIRA, a practical board might have columns like Backlog, To Do, In Progress, Design Review, Development, QA Testing, and Ready for Production. This structure ensures that design handoff, code review, and quality assurance are all visible and tracked. The tradeoff is that adding too many columns slows down the daily standup—teams reviewing a board with eight columns spend time discussing work that’s barely changed, whereas a board with four columns keeps updates focused. Start with the minimum viable set of columns and add more only after you’ve run at least two sprints and identified missing visibility.
Estimating Work with Story Points and Sprint Capacity
Story point estimation is the practice of assigning relative complexity scores to each issue, which helps teams understand how much work fits into a sprint. Most teams use a Fibonacci-like scale: 1, 2, 3, 5, 8, 13, and 21 points, where 1 is trivial and 21 is a major feature requiring a full sprint. JIRA displays a “Story Points” field in the issue details, and estimating happens during sprint planning.
The advantage of story points is that they’re relative—your team decides what a 5 means based on your own velocity, rather than comparing to an external standard. However, estimating is notoriously difficult, and many new teams either under-estimate dramatically (leading to sprint failures) or over-estimate to be safe (which defeats the purpose). A practical approach is to avoid over-analysis: spend five minutes estimating each item during planning, estimate as a team using planning poker to expose differing perspectives, and track your velocity for three to four sprints before using it for forecasting. A comparison: if your team consistently completes 30 story points per sprint, and a feature is estimated at 40 points, you know it spans the sprint boundary and you’ll need to split it or plan a longer sprint.
Avoiding Sprint Overload and Managing Mid-Sprint Changes
One of the most common mistakes is stuffing too much work into a sprint, which demoralizes the team and generates false velocity metrics. JIRA helps here by showing your sprint’s total story point load during sprint planning, but it’s up to you to make the hard choice about what fits. A typical team should fill only about 80-90% of their suspected capacity to account for unexpected interruptions, bug fixes, and support requests.
A warning: if your organization frequently adds new work mid-sprint without removing something else, your sprint is no longer a commitment, and you lose the forecasting value. Some teams handle this by designating a “flex allocation”—perhaps 20% of sprint capacity is reserved for ad-hoc work, and everything else is locked in after sprint planning. This requires discipline and clear communication with stakeholders who might expect mid-sprint requests to always fit. Another limitation is that JIRA doesn’t prevent you from adding work mid-sprint; it requires process discipline rather than tool enforcement.
Using Burndown Charts to Track Daily Progress
JIRA automatically generates a burndown chart that shows whether your team is on pace to complete the sprint. The chart plots ideal progress (a diagonal line from the sprint starting point to zero remaining work) against actual progress (a jagged line reflecting your team’s daily velocity). If your actual line trends above the ideal line, your team is behind schedule and may need to cut scope or extend hours as the sprint deadline approaches.
For a real example, a team might see their burndown chart show steady progress for the first week, then realize on Thursday that they’ve only completed 40% of the sprint work with three days remaining. This visibility prompts an honest conversation: should we reduce scope for this sprint, push the deadline, or commit to extra hours? Many teams find that simply having the burndown chart visible during daily standups improves team focus and early problem detection. Access the burndown chart from your board’s “Reports” menu, and review it each day to maintain sprint awareness.
Scaling Your Scrum Setup as Your Team Grows
As your team expands from 5 people to 10 or more, your Scrum board setup may need adjustments. Larger teams often split into smaller scrum teams, each with their own board, but some organizations prefer a single board with multiple teams represented by different labels or custom fields. JIRA’s portfolio tools (like JIRA Align or Atlassian Portfolio) help manage dependencies across teams when you reach a certain scale.
Looking ahead, many organizations are moving toward hybrid approaches—combining Scrum’s sprint structure with Kanban’s continuous flow for support and maintenance work. As your team matures and collects velocity data, you’ll also discover whether two-week sprints remain optimal or whether your workflow has evolved to need different pacing. The board you set up today is the foundation, but it will—and should—evolve as your team learns what works best.
Conclusion
Setting up a Scrum board in JIRA requires creating a project, defining sprints, populating your backlog with issues, and customizing your workflow columns to match your team’s actual process. The technical setup is straightforward, but the real work is teaching your team to estimate reliably, commit to realistic workloads, and use the board’s data (burndown charts, velocity metrics) to improve forecasting over time. Start with a minimal configuration—basic columns, one sprint, and simple estimation—then refine after running two or three sprints and observing what information your team actually needs during standups and retrospectives.
The success of your Scrum board depends far more on how your team uses it than on JIRA’s configuration options. Dedicate time during your first retrospective to discussing what’s working, what’s confusing, and what columns or fields should be added or removed. This iterative approach to your process, mirroring your iterative approach to software development, is what transforms JIRA from a task-tracking tool into a genuine visibility mechanism that helps your team ship better work faster.
Frequently Asked Questions
How many story points should a single sprint contain?
Most teams aim for 20-40 story points per sprint, but your team’s velocity will depend on complexity, team size, and sprint duration. Calculate your team’s velocity by tracking completed story points over three to four sprints, then use that number to plan future sprints. Don’t aim for perfection—hitting 80-90% of your target consistently is considered excellent performance.
Can I change a sprint’s duration after it starts?
You can modify sprint duration in the sprint settings, but changing duration mid-sprint creates confusion with planning and forecasting. It’s better to commit to your chosen duration for at least three sprints before adjusting. If you find two weeks consistently doesn’t work, switch to one week or three weeks for the next sprint rather than mid-stream changes.
What’s the difference between a story point estimate and time estimate?
Story points represent relative complexity; time estimates represent hours or days. Story points are superior for agile teams because they’re more consistent—a 5-point story remains a 5-point story regardless of who works on it, whereas the same work might take one developer 4 hours and another 8. Use story points exclusively in your sprints.
Should subtasks appear on the Scrum board?
By default, subtasks don’t display on the Scrum board; only parent issues do. This keeps the board clean and focused on actual deliverables. If your team needs to track subtasks, create them as child issues but plan your capacity around parent issues, not subtasks.
How do I handle bugs that appear mid-sprint?
Critical production bugs should be pulled into the sprint (removing lower-priority work to maintain capacity), while non-critical bugs stay in the backlog for the next sprint. Distinguish between categories during your sprint planning to avoid constant scope creep. A discipline many teams find helpful: any bug added mid-sprint requires removing an equal amount of story points.
Can multiple teams share a single JIRA board?
Technically yes, but it becomes unwieldy around five people and nearly impossible beyond that. Use team labels or custom fields to segment work, or create separate boards for each team with a portfolio view to show cross-team dependencies. Separate boards scale better and improve each team’s ownership of their process.
