JIRA Sprints and Backlog Management
Sprints and the backlog form the heartbeat of Scrum-based project management in JIRA. The backlog holds all planned work. A sprint is a time-boxed period where the team commits to completing a specific slice of that backlog. Together, they create a repeatable planning-delivery cycle that gives teams consistent forward momentum. This topic covers every aspect of managing sprints and the backlog inside JIRA.
What Is the JIRA Backlog?
The Backlog is a prioritized list of all issues in the project that have not yet been completed. It lives below all active sprints in the Backlog view. The Product Owner owns the backlog — they add new issues, prioritize existing ones, and remove stale ones regularly. A well-maintained backlog is the team's roadmap for upcoming work.
| Section | What It Contains |
|---|---|
| Sprint 1 (Active) | Issues currently in the running sprint |
| Sprint 2 (Next Sprint) | Issues planned for the upcoming sprint (not yet started) |
| Backlog Section | All remaining issues with no sprint assigned — in priority order |
Backlog Best Practices
| Healthy Backlog | Unhealthy Backlog |
|---|---|
| Top 20–30 items are detailed and estimated | Hundreds of items with no description or estimate |
| Ranked by business priority — most important at top | No clear ranking — team debates priority every sprint |
| Reviewed and groomed weekly (Backlog Refinement) | Items added months ago still in backlog unchanged |
| Stale issues archived or deleted | Old bugs from 2 years ago still marked as open |
| Each story has acceptance criteria written | Stories have only a one-line title with no detail |
Backlog Refinement (Grooming)
Backlog Refinement is a regular meeting (usually 1 hour per week) where the team reviews the backlog together. The goal is to ensure upcoming issues are well-understood, estimated, and ready to be pulled into a sprint.
| Activity | Who Participates | JIRA Action |
|---|---|---|
| Review top backlog items | Product Owner, Dev Team | Open each issue, read description, clarify details |
| Add or update acceptance criteria | Product Owner | Edit the issue Description field |
| Estimate story points | Dev Team (using Planning Poker) | Set the Story Points field on each issue |
| Break large stories into smaller ones | Dev Team, Product Owner | Create new child issues or split the original |
| Reprioritize issues | Product Owner | Drag issues up or down in the backlog list |
| Remove outdated issues | Product Owner | Delete or resolve the issue as "Won't Do" |
Story Points: Estimating Effort
Story points are a unit of measure for the relative effort required to complete an issue. They do not represent hours directly. Instead, they represent a combination of complexity, uncertainty, and volume of work. Teams use a modified Fibonacci sequence for estimation: 1, 2, 3, 5, 8, 13, 21.
| Points | Effort Level | Example Task |
|---|---|---|
| 1 | Trivial — 1–2 hours | Fix a typo in a UI label |
| 2 | Small — 2–4 hours | Add a tooltip to an existing button |
| 3 | Simple — half a day | Add a new field to an existing form |
| 5 | Medium — 1 to 2 days | Build a simple CRUD screen with validation |
| 8 | Large — 2 to 3 days | Integrate a third-party payment API |
| 13 | Very Large — most of a sprint | Build a multi-step registration wizard |
| 21 | Too large — must be broken down | Any item at 21 points should be split into smaller stories |
What Is a Sprint?
A sprint is a fixed-length work period — typically 1 to 4 weeks — during which the team commits to completing a specific set of backlog issues. Sprint length stays constant from sprint to sprint. Once a sprint starts, the team does not add new work unless the Scrum Master and Product Owner agree it is critical.
Sprint Lifecycle in JIRA
| Phase | Activity | JIRA Action | Who Leads |
|---|---|---|---|
| 1. Create Sprint | Create a blank sprint in the backlog | Click "Create Sprint" in Backlog view | Scrum Master |
| 2. Sprint Planning | Select and move issues from backlog into the sprint | Drag issues from backlog into the sprint section | Product Owner + Dev Team |
| 3. Start Sprint | Set sprint name, goal, start date, and end date | Click "Start Sprint," fill the dialog box | Scrum Master |
| 4. Execute Sprint | Team picks up issues, updates statuses, logs work | Move cards on the Scrum Board daily | Development Team |
| 5. Sprint Review | Demo completed work to stakeholders | Show issues in Done column of the board | Dev Team + Product Owner |
| 6. Sprint Retrospective | Discuss what went well, what to improve | External meeting — JIRA not directly used | Scrum Master |
| 7. Complete Sprint | Close the sprint, move incomplete issues | Click "Complete Sprint," choose destination for open issues | Scrum Master |
Creating a Sprint in JIRA
Step-by-Step Process
| Step | Action |
|---|---|
| 1 | Open the project and click Backlog in the left sidebar |
| 2 | Click Create Sprint — a new empty sprint block appears at the top of the backlog |
| 3 | Drag issues from the Backlog section into the new sprint block |
| 4 | Review the total story points shown in the sprint header — compare to team velocity |
| 5 | Click Start Sprint |
| 6 | Fill in Sprint Name (e.g., "Sprint 6 — Payment Module") |
| 7 | Add a Sprint Goal — a one-sentence description of what the sprint delivers |
| 8 | Set Duration or manually enter start and end dates |
| 9 | Click Start — the sprint is now live and the board shows the sprint issues |
The Sprint Goal
The Sprint Goal is a one-sentence statement that describes the business outcome the team aims to deliver by sprint end. A good sprint goal keeps the team focused when unexpected work arrives.
| Sprint | Sprint Goal |
|---|---|
| Sprint 3 | Complete the user authentication flow so that users can register, log in, and reset passwords |
| Sprint 5 | Deliver the payment checkout screen so that users can pay using UPI and debit cards |
| Sprint 8 | Fix all P1 and P2 bugs from the beta release so that the app is stable for public launch |
Team Velocity
Velocity measures how many story points a team completes per sprint on average. Teams use past velocity to decide how much work to commit to in the next sprint. A team with a velocity of 30 points should not commit to 50 points in the next sprint.
| Sprint | Committed Points | Completed Points | Velocity |
|---|---|---|---|
| Sprint 1 | 40 | 28 | 28 |
| Sprint 2 | 30 | 30 | 30 |
| Sprint 3 | 32 | 29 | 29 |
| Sprint 4 | 30 | 32 | 32 |
| Sprint 5 | 32 | 31 | 31 |
| Sprint 6 | 32 | 30 | 30 |
| Average | 30 points |
Completing a Sprint
When the sprint end date arrives, the Scrum Master closes the sprint using the "Complete Sprint" button. JIRA shows a completion summary and asks where to send incomplete issues.
| Issue State | Options | Recommended Choice |
|---|---|---|
| In Progress / To Do issues | Move to Backlog OR Move to Next Sprint | Move to next sprint if the work is still relevant and important |
| Done issues | Archived in the completed sprint automatically | No action needed |
Summary
The backlog is the team's master list of all planned work, organized by priority and ready for sprint planning. Sprints give the team a focused, time-boxed container for delivering a meaningful slice of work. Backlog refinement ensures issues are well-understood before they enter a sprint. Story points provide relative estimates for capacity planning. Team velocity tells the team how much to commit in each sprint. The sprint lifecycle moves from planning through execution to review and retrospective. With sprints and backlog management fully understood, the next step is learning how to search and filter issues effectively using JIRA's powerful query system — Filters and JQL.