Blog · 26 September 2026

Jira for sprint planning: a meeting that fits in an hour

Using Jira for sprint planning comes down to three screens: the backlog, where the team ranks and estimates work; the sprint container at the top of it, where the chosen items are dragged; and the Start sprint dialog, where you set the dates and the goal. The meeting itself goes well or badly for reasons that happen before anyone opens the backlog. The backlog was not refined, the estimates are missing, or the routine work the team does every sprint was never written down and quietly eats a third of the capacity. This guide walks the meeting in order, then deals with that last problem, because it is the one Jira leaves entirely to you.

A note on words. Jira Cloud has been renaming things: projects are now spaces and issues are now work items in much of the interface. This article uses both, since most teams still say "issue".

What sprint planning in Jira actually involves #

Sprint planning answers two questions: what will the team finish in this sprint, and why does that set matter. In Jira that turns into a short list of concrete actions.

Most of the work in that table happens before the meeting starts. A planning session that begins with an unranked backlog becomes a refinement session, and the sprint starts a day late.

Before the meeting: get the backlog ready #

Rank the backlog #

Open the space, then the Backlog tab. Everything below the sprint containers is the backlog, in rank order. Drag the items you most want done to the top. Rank is the single most useful signal in the meeting, because the team pulls from the top down and stops when it is full.

If your board has more than a few dozen items, use a quick filter or the epic panel to narrow the view. An epic that is not ready to start this sprint should not have its children sitting at the top of the list.

Estimate the top of the list #

The team estimates enough items to cover roughly one and a half sprints of work. Story points are the most common unit in scrum boards; time estimates and work item count are the alternatives, set in the board's estimation settings. Whichever you pick, pick one and keep it, because the velocity chart only compares like with like.

Items that cannot be estimated are a signal. Either split them, or add a spike to find out what they involve.

Check capacity #

Open Reports, then the Velocity chart, and look at what the team actually completed over the last three to five sprints. That completed figure, adjusted for holidays and people out, is the capacity for the coming sprint. The committed figure on the same chart is what the team hoped for, and the gap between the two is worth a sentence in the retrospective.

Then subtract the work nobody plans but everybody does. That is the step most teams skip, and it has its own section below.

During the meeting: build the sprint #

1. Create the sprint if it does not exist. At the top of the backlog, select Create sprint. Jira names it after the board and a number, which you can change.
2. Restate the goal from the product owner. One or two sentences on what the sprint is for. Everyone should be able to say it without looking.
3. Drag items from the backlog into the sprint, from the top, discussing each. The sprint container shows a running total of the estimate, so you can see capacity filling up.
4. Break down anything big. Add subtasks where a story needs several people or several days. Subtasks help the daily standup more than they help the plan.
5. Stop at capacity. When the total reaches the number you worked out before the meeting, stop. Leftover items go back to the top of the backlog for next time.
6. Select Start sprint. Set the name, the start date and the end date, and add the Sprint goal. Atlassian's own documentation notes that the sprint goal is shown on the Sprint Report and the Burndown Chart, which is a good reason to write one worth reading.

After you select Start, Jira takes you to the active sprint board. Anything added or removed from now on counts as a scope change and shows up in the burndown.

The recurring work that never makes it into the plan #

Every team has work that returns on a rhythm: the dependency update every two weeks, the monthly access review, the release checklist, the on-call handover, the retrospective itself. It is real work that takes real hours. It rarely appears in the backlog before planning, for a simple reason: nobody creates a ticket for something that has not happened yet.

So one of two things happens. Either someone remembers mid-sprint and adds it, which Jira records as scope change and which drags the burndown off its line. Or nobody remembers, the work is done anyway without a ticket, and the velocity chart under-reports what the team does. Both make the next planning session less accurate than the last.

The fix is to have that work in the backlog before the meeting, every time, without relying on memory.

Three ways to get recurring work into the backlog #

By hand works for a team with two or three recurring items and a disciplined scrum master. Put a checklist in the planning agenda: "create this sprint's recurring tickets". It stops working when that person is on leave.

Jira Automation can do it with a Scheduled trigger and a Create work item action. As of September 2026 it is included with Jira, and it is the right choice for a site that already runs a lot of Automation and has room under its limits. The details, including how each run counts, are in Jira Automation pricing and Jira Cloud automation limits. Expressing "every second Monday" in a scheduled rule means a cron expression, which has its own traps.

A scheduling app holds the schedule and the ticket template together, per space. Recurring Work Items for Jira is built for this job: a project admin writes the rule once, and the work item appears in that space's backlog on the day it is due, with its description, assignee, labels, due date and subtasks already filled in. Titles and dates can carry tokens, so the ticket reads "Dependency update, sprint of 5 Oct" rather than a copy of last time's summary.

Timing the recurring tickets for planning #

Whichever tool creates the tickets, create them a day or two before the planning meeting, not on the day the sprint starts. That way they sit in the backlog when the team is ranking and estimating, and they are counted in capacity like any other item.

A few rules make this reliable:

• Give each recurring ticket an estimate in the template. A dependency update that always takes about three points should arrive with three points, so capacity is right without discussion.
• Use a label such as recurring so the team can filter them in the backlog and see how much of each sprint they take.
• Skip the new ticket if the previous one is still open. Otherwise a skipped chore turns into two identical tickets. Recurring Work Items has this as a rule option ("only create if the previous issue is closed"); in Automation it takes a JQL lookup before the create action.
• Respect working days. A ticket due on a public holiday gets missed. Recurring Work Items lets each project set its working days and decide per rule whether to move a due date that lands outside them.

Two related guides go further: Jira recurring tasks compares the options in more depth, and Jira retrospective template covers the ceremony that closes every sprint.

When the manual way is enough #

Not every team needs another tool. Planning by hand is fine when:

• the team has only two or three recurring jobs, and the same person runs every planning meeting;
• the recurring work is already represented another way, such as a fixed capacity deduction everyone agrees on;
• the team runs Kanban rather than sprints, so there is no planning meeting to prepare for.

In those cases a line in the planning agenda does the job. Add an automated approach when a recurring job has been forgotten twice, because by then the checklist has shown it does not hold.

Common sprint planning mistakes in Jira #

• Planning to the committed number, not the completed one. The velocity chart shows both; plan to what the team finished.
• Starting the sprint with no goal. The goal field is optional in the Start sprint dialog. Leaving it blank makes the Sprint Report harder to read later and gives the team nothing to trade scope against mid-sprint.
• Using subtasks as a to-do list for the whole team. Subtasks belong to a story. Work that stands alone should be its own ticket so it can be ranked.
• Letting routine work stay invisible. If the team always spends a day on releases, that day belongs in the plan as a ticket.
• Changing the estimation unit halfway through a quarter. Velocity comparisons stop meaning anything.

Frequently asked questions #

Can Jira create a sprint automatically? Jira does not start sprints on a schedule by itself. You create and start each sprint from the backlog. Automation can react to sprint events, such as a sprint starting or completing.

Where do I set the sprint length? In the Start sprint dialog, by choosing the start and end dates. There is no separate board setting that fixes the length for every sprint.

What happens to unfinished items at the end of a sprint? When you complete the sprint, Jira offers to move incomplete items to the next sprint or back to the backlog.

Should recurring chores be stories or tasks? Tasks, usually. They rarely describe user value, and keeping them as a separate work type lets you report on how much time they take.

If routine work keeps surprising your plans, set up the recurring tickets once and let them arrive before the next planning meeting.