Sprint Planning in Jira: Step by Step, Plus the Gaps

Jira sprint planning is the meeting where a Scrum team picks a sprint goal, pulls ready work into a sprint, and starts the board. In Jira Software you create the sprint on the backlog, order and estimate issues, check capacity, and then start the sprint so the active board fills up. The steps below follow that path and then cover what the tool still leaves to the team.

How Jira sprint planning actually runs

Jira stores the sprint, the issues, and the board columns. It doesn't decide the goal or where the cut line goes. To get a useful session you need a ready backlog, a known capacity, and a goal the team can say out loud. Atlassian's sprint planning overview describes the meeting as a negotiation between a goal and a forecast of work, which fits how the product is built: sprints are containers and issues are what goes in them.

If the ceremony itself is new to you, read Sprint Planning: A Complete Guide for Teams That Ship Every Week first. This page covers the Jira sequence and the decisions the board won't make for you.

What to prepare the day before

Filter the backlog down to issues refined enough to start. A ready issue has a clear outcome, acceptance notes, an estimate, and no known blocker. Spikes and half-specified stories stay on the product backlog. It's the same split described in sprint backlog vs product backlog: the sprint holds only work you intend to finish inside the timebox.

Check three things before the call:

• The previous sprint is closed, or you've already chosen which unfinished issues go back to the backlog.
• Estimates use one unit. If you mix story points and hours, the footer total means nothing.
• Absences are written down (holiday, on-call, release freeze). Capacity fields only know the calendar if someone typed it in.

A sprint planning meeting agenda that fits in one hour stops this prep from turning into a second refinement session.

Create the sprint

On a Scrum backlog, create the sprint at the top of the list. Give it a name that keeps reports readable ("Sprint 42" or "24 Mar to 4 Apr"), set the start and end dates, and add the goal once you have one. Most teams create it empty and drag issues in. You can also create the next sprint while the current one is still active, which gives refinement somewhere to park work off the active board.

That's the create new sprint Jira action, and the dates matter more than the name. The burndown, the start action, and the complete action all run off those dates. A two-week sprint that goes Wednesday to Tuesday is fine if that's when people are in, but a wrong end date skews every chart that follows.

Don't start the sprint yet. Starting it moves the issues onto the active board and kicks off the burndown, and planning is easier while the sprint is still a future container.

Order the work and estimate what is still open

Drag ready issues into the order you'd pick them up. Goal work goes first, and bugs that have to ship with that goal sit next to the stories they belong to.

Only estimate in the meeting when the team understands the issue and it doesn't have points yet. If it turns into a long argument, send the issue back to refinement. Sprint poker helps when estimates differ by more than one step on the scale. Skip it when refinement already agreed on a number and one person wants to reopen it.

The sprint footer adds up the estimates, but that sum isn't the commitment. The commitment is what's left after you compare it with capacity and make the cut.

Set capacity, the goal, and the cut line

Capacity is how much estimated work this team can finish, not how many hours sit on the calendar. Take the last three completed sprints, drop an outlier you can explain, and use the middle one as the budget. That history is your velocity. It tells you what similar sprints finished, and it makes no promise about the next one.

Subtract absences in the meeting, out loud. If one person is gone for the whole sprint, you don't plan a full load.

Write the goal in the sprint goal field as one sentence someone can still repeat on day six. If it takes a paragraph, you have two goals. Then draw the cut: issues above the line fit the goal and the budget, and issues below it stay on the backlog. Leave "stretch" issues out of the sprint, because they teach stakeholders that the commitment is soft.

Start the sprint

Start once the goal is saved, the footer is inside the budget, and every included issue is ready. Confirm the dates in the dialog.

Jira will let you drag new issues onto an active sprint later, but being allowed to doesn't make it a process. Only add mid-sprint work by swapping out something of similar size, and mention it at standup. A commitment can double through quiet additions that nobody announces.

A worked example

This is an illustration, not a benchmark. Northwind is a squad of four engineers, one designer, and one product manager working ten days. Their last three sprints finished 27, 31, and 29 points, so the planning budget starts at 29.

Two engineers are each out for two days, and the team cuts the budget to 24 instead of inventing a headcount formula. The product manager brings eight ready stories and three bugs for one goal: "A merchant can issue a partial refund without finance opening the admin tool."

They create "Sprint 18 · 6 Apr to 17 Apr" and drag in five stories and two bugs totaling 23 points. One unestimated story would add 5 and take the sprint to 28, so it stays on the backlog. They save the refund sentence as the goal and start the sprint.

The whole thing takes about forty minutes. They spend the rest of the time on risks the estimate field can't hold: a dependency on the payments vendor, and refund email copy that isn't final yet. Those go in a note next to the goal, or on a checklist issue the team already uses.

Where Jira for sprint planning is enough

Jira for sprint planning works for a single squad with a refined backlog and a simple in-or-out decision. The backlog, the footer, the goal field, the active board, and the burndown make up the whole loop. Parallel sprints help when two small teams share a project, and a clear column scheme matters as much on day three as the meeting did.

Epics and versions give you the coarser view. An issue in a version isn't the same as an issue in this sprint, so if leadership reads the version and the team reads the sprint, say which one is the commitment.

Jira is a system of record. It won't tell you the goal is really two goals, it won't refuse a sprint that jumped forty percent, and it won't stop a complete-sprint click that dumps unfinished work into the next container without review.

Gaps to close on purpose

Rollover without a review. Completing a sprint moves unfinished issues to the next sprint or the backlog in a single dialog, and the risk is how fast that happens. Each leftover needs a decision: keep it in scope, split it, or drop it. Falrow's cycles put that review on the schedule. In Jira, make the same pass part of closing the sprint, or part of your next scope will be an accident.

A single velocity number. The velocity chart and the burndown describe recent totals and the current sprint. They can't give you a range for "when does this epic finish?" For a statement like "half the time by this date," you need cycle time, a picture of where work is sitting, and a forecast that replays the history many times. Cycle time percentiles, cumulative flow, and Monte Carlo forecasts exist for that question. If you're staying in Jira, export cycle times and don't present one average as a confidence interval.

Work that never becomes an issue. Calls, chat, and production errors only become part of the real sprint once someone files them. Leave planning with a named list of tickets still to create, and create them before the next standup. A draft ticket isn't scope until a person accepts it.

Capacity with no note. If you cut 29 points to 24 because two people are out, write that down. Later on, the chart won't explain itself.

A sequence you can run this week

These times assume a refined backlog and a two-week sprint. If refinement was skipped, give the middle steps more time, but don't fill it with stories nobody has read.

Minute	What happens	Jira action	Owner
0 to 5	Dates, absences, capacity budget	Dates checked, budget written beside the goal	Scrum lead
5 to 15	One-sentence sprint goal	Draft ready, not saved yet	Product manager
15 to 35	Pull ready issues up to the budget	Drag into the future sprint	Whole team
35 to 45	Cut, name risks and missing tickets	Goal saved, leftovers stay on the backlog	Whole team
45 to 55	Start and state the commitment	Start sprint, dates confirmed	Scrum lead

The capacity math and the commitment line also fit on a sprint planning template. The template holds the numbers and Jira holds the issues.

The next morning, the active board should still match the goal. If scope appeared overnight, it came from somewhere, so either swap something out or say the commitment changed. Complete the sprint on the end date even if work remains. Sliding the date to protect the burndown erases the history you'll use as the next sprint's budget.

Jira sprint planning comes down to those decisions stored in one container: create it, fill it against a real budget, write one sentence, and start it. Jira keeps track of the issues. The goal, the cut line, and the rollover review are the record of why those issues belonged in the sprint.

FAQ

How do I create a new sprint in Jira?

Open the Scrum backlog, choose Create sprint, and set the name and the start and end dates. Drag ready issues in, add the goal, and only start the sprint once the team agrees on the commitment. The next sprint can wait as a future sprint while the current one is active.

What is the difference between a sprint and the backlog in Jira?

The backlog is ordered work that isn't in a timebox yet. A sprint is a dated container for the forecast. Starting a sprint puts its issues on the active board, and completing one asks where the unfinished issues should go. Planning is when you move issues from one to the other on purpose.

How many points should we put in a Jira sprint?

Use the middle of the last few completed sprints, then subtract known absences. A point only means something inside one team, so there's no universal number. If recent totals swing wildly, fix estimation and unplanned scope before you trust the footer.

Can we change the sprint after it has started?

Jira lets you add new issues and change the goal or the dates. Change dates rarely, because the burndown and your history both depend on them. Treat scope changes as a swap: something comes in, something of similar size goes out, and the team hears about it. If a sprint absorbs every request, there's no commitment left to report on.