Managing Scrum Backlogs and Sprints in Jira

Hello. Last lesson established the difference between Jira’s work hierarchy, issue links, statuses, and versions. This lesson puts that model to work: you’ll prepare a Scrum backlog, select a realistic sprint scope, keep the sprint accurate while work changes, and close it without losing track of unfinished issues.

The emphasis is on actions you can take from a manager-level account. You do not need to create a project or redesign its workflow. We’ll use current Jira Cloud guidance for the mechanics and point out where an older Jira Server interface may differ.

---

1. Know what the backlog is showing you

A Scrum backlog is a planning view of issues available to the board, with separate sections for work assigned to sprints. It is not necessarily every open issue in the project. The board’s filter and column configuration determine what appears. That matters when a manager hears, “The bug exists, but I can’t find it in the backlog.”

In the image, three issues are in the active sprint and five remain in the backlog. The items still in the backlog have not vanished from the project; they simply are not assigned to that sprint.

Read the beginning of Atlassian’s Use your scrum backlog to establish the visibility rules. Then skim the specified task rows in its backlog-management table. The documentation uses Cloud terms such as work item and space; an older Server installation will usually say issue and project.

An issue may be absent because it is a sub-task, fails the board’s saved filter, or has a status that does not meet the backlog’s column-mapping rules. A quick filter you have selected can also narrow what you see. Before recreating a supposedly missing bug, open it by its key and check its project, status, and board eligibility. If the board filter or column mapping is wrong, report the finding to a board administrator rather than treating it as an issue-creation problem.

Backlog rank is the team’s ordering of work. It is distinct from Jira’s Priority field: two bugs can both be marked “High” while one is ranked above the other for the next planning discussion. When you reorder items, make the reason visible to the team—especially if a quality or release risk has displaced previously planned work.

---

2. Refine issues before promising them for a sprint

Return to the account-recovery capability from the previous lesson. Imagine its backlog contains a story for requesting a recovery link, a story for rejecting expired links, an integration task for sending the email, a reproduced bug concerning expired links, and a lower-priority story for throttling repeated requests.

A manager’s preparation is more than arranging those five rows. Before selecting sprint work, inspect each candidate issue:

• Scope and evidence: Does a story have testable acceptance criteria? Does the bug distinguish expected from actual behavior and provide reproduction details?
• Relationships: Are the stories associated with the appropriate epic? Is the email integration task linked as a blocker if the recovery-link story genuinely depends on it? Is the bug linked to the behavior it affects?
• Readiness: Is the work small enough to finish and verify within the sprint? Are external dependencies, test data, and responsible people understood?
• Estimate: If the team uses story points or time estimates, are estimates present and comparable under its agreed convention? An estimate supports a capacity conversation; it does not certify that an issue is ready.

An issue that is too large should be refined or split into independently understandable work before it silently consumes a sprint. Do not replace the parent story with a collection of sub-tasks merely to make the backlog look smaller: as the earlier lesson established, sub-tasks are a breakdown of one standard issue, not independent backlog commitments.

For the example, a plausible sprint goal is “Demonstrate a recovery-link request and rejection of an expired link, with QA verification.” The request and expiry stories, the integration task, and the existing expiry bug might support that goal. The throttling story can remain ranked in the backlog. If the integration task is blocked by work outside the team, resolve that planning risk before presenting the whole set as a confident commitment.

---

3. Create, fill, and start the sprint

Watch this short demonstration before using the controls yourself. It shows the planning sequence without requiring you to create a new project.

The corresponding Cloud instructions are in Atlassian’s backlog guide:

On an existing Scrum board, the practical sequence is:

1. Review and rank the eligible backlog. Confirm which issues serve the proposed goal and which should remain unscheduled.
2. Create a sprint section if one does not already exist. Move selected standard issues from the backlog into it, typically by dragging them or using the available issue menu. Check the sprint contents afterward; moving an issue into a sprint changes its sprint assignment, not its workflow status.
3. Check scope against capacity and dependencies. An issue count alone is misleading: three small, ready items may be safer than one large, blocked story. Discuss estimates using your team’s established method rather than assuming story points convert directly to days.
4. Set a meaningful sprint goal and dates, then start the sprint. The goal describes the outcome the selected work is meant to achieve. Starting the sprint makes it active on the board; it does not move every issue to “In Progress.”

You can usually create future sprint sections while one sprint is active, but a future sprint does not start merely because issues have been assigned to it. The Atlassian guide describes one active sprint in its standard setup; parallel sprints, where enabled, change that constraint.

In older Jira Server, look for Backlog, Active sprints, and the sprint’s menu or Start sprint control, although placement and wording may vary. In Cloud, navigation also varies between company-managed and team-managed projects. If Create sprint, Start sprint, ranking, or issue editing is unavailable, check permissions before assuming the feature is missing. Sprint controls commonly require Manage Sprints permission; assigning or editing issues and ranking work require their relevant permissions and board setup. A board spanning several projects can add permission complications. Ask an administrator to check the specific board and account rather than changing project configuration yourself.

---

4. Keep the sprint truthful as work develops

Once a sprint is active, use the Active sprints board to check which issues are actually moving through the workflow. Status updates should represent work done, not a desired reporting picture. For a QA-sensitive goal, agree what the board’s final column means: if verification is required but has not happened, placing an issue in that column would overstate completion.

New information will arrive. A reproduced, urgent defect might need to enter the active sprint; a lower-value item might need to leave it. Jira permits changes to active-sprint scope, but make the decision explicit: identify what changed, why it matters to the sprint goal, and what capacity is being displaced. Keep the issue’s links and evidence intact so the change remains intelligible after the sprint ends. A flag can make an impediment visible; it does not resolve the dependency or change the issue’s status by itself.

Atlassian’s guide also documents splitting an oversized item and flagging a blocked one:

That copying detail is important for QA: after a split, verify that each resulting issue has the requirement or defect links it needs. Do not assume the new issue inherits the original’s full traceability.

At sprint end, reconcile Jira with the work that actually meets your team’s completion criteria. Atlassian’s completion guide states the board rule Jira uses: issues in the last column count as complete; issues in other columns count as incomplete. That is a mechanical rule, not proof that acceptance criteria or testing passed.

Before selecting Complete Sprint, inspect items that appear done, including relevant sub-tasks and QA evidence, and correct any inaccurate statuses through the permitted workflow. Then choose where incomplete issues should go: backlog, an existing future sprint, or a newly created sprint. Do not carry everything forward automatically. Reassess each item’s priority, remaining work, and relationship to the next sprint goal. Completing a sprint does not itself fix a bug, close an unfinished issue, or make a release ready.

---

Conclusion

A reliable Scrum plan depends on three distinct things staying aligned: backlog rank communicates ordering, sprint assignment communicates planned scope, and status communicates an issue’s actual progress. Prepare issues and dependencies before selecting them, start the sprint around an outcome rather than a collection of tickets, and make mid-sprint changes and carryover decisions visible. With manager-level access, you can do much of this directly; when a board setting or permission prevents it, identify the specific obstacle for an administrator.

Next, we’ll move from the board to basic issue search and saved filters, so you can find, share, and monitor work that a single backlog view may not show.