Sprint planning has a bad reputation, and honestly? Most of the time it’s earned. The meeting drags. Half the room is checking Slack. Someone discovers a “quick” story actually needs a database migration. And at the end, nobody’s quite sure what they agreed to.
It doesn’t have to go like that. The mechanics in Jira are genuinely simple — the part that goes wrong is almost always the prep. Let’s walk through the whole thing the way it actually works when a team has its act together.
What you need before the meeting starts
Here’s the uncomfortable truth: the quality of your sprint planning is decided before anyone sits down. Walk in with a messy backlog and no amount of clever facilitation saves you.
Before planning, you want three things in place:
- A refined backlog. The top items are estimated, have a clear “done” definition, and aren’t blocked by some unanswered question. This comes out of backlog refinement, not the planning meeting itself.
- A sprint goal in mind. One sentence describing what this sprint is for. “Ship the new checkout flow” beats “do 14 tickets” every time.
- A real sense of your team’s capacity. Not the theoretical max — the actual hours or points available once you subtract PTO, holidays, on-call, and the meeting tax everyone pretends doesn’t exist. More on that in a minute.
If those three aren’t ready, fix that first. Seriously. A 20-minute refinement session the day before will save you an hour of confused debate during planning.
Step 1: Open your Scrum board and find the backlog
In Jira, sprints live on Scrum boards (Kanban boards don’t have them). From your project, open the board, then click into the Backlog view. You’ll see your sprint section at the top — usually an empty “Sprint 1” or similar — and the product backlog stretching out below it.
If there’s no sprint container yet, hit Create sprint. Jira drops an empty sprint above the backlog, ready to fill.
Step 2: Set the sprint goal and dates
Click Edit sprint (or the little pencil / three-dot menu on the sprint header). Here you’ll set:
- Sprint name — keep it boring and sequential, or tie it to the goal.
- Duration — one to four weeks. Two weeks is the most common, and for good reason: it’s long enough to ship something meaningful, short enough that you don’t drift.
- Start and end dates — these matter more than people think, because they’re what your capacity math is built on. A sprint that spans a public holiday is not the same size as one that doesn’t.
- Sprint goal — that one sentence. Write it down where the team can see it.
Step 3: Pull work into the sprint
Now the actual selection. Drag stories from the backlog up into the sprint, or select several and use Add to sprint from the right-click menu.
The order you pull matters. Start with anything that directly serves the sprint goal. Then dependencies and carry-over from last sprint. Then the nice-to-haves, if there’s room.
And here’s the discipline part — stop pulling before the bar fills up. The single most common sprint planning mistake is committing to 100% of capacity, leaving zero slack for the bug that lands on day three, the code review that takes longer than expected, or the meeting nobody scheduled yet. Plan to about 80% and you’ll actually hit your commitments instead of explaining why you didn’t.
Step 4: Estimate anything that slipped through
Ideally every story is already estimated from refinement. Ideally. In the real world, one or two always sneak in unestimated, and planning is your last chance to size them.
This is where teams run planning poker — everyone votes on an estimate at the same time so nobody anchors to the loudest voice in the room. If you’re estimating in Jira, you can update the Story Points (or original time estimate) field directly on each issue. Whatever your unit, get a number on every committed item. An unestimated story in a sprint is a little time bomb.
Step 5: Assign owners and check capacity
This is the step most teams half-do, and it’s the one that separates a plan that holds from a plan that’s basically a wish.
Assign owners — at minimum for the first few days of work per person. Then compare what each person is carrying against what they can actually do.
Let me make that concrete. Say you’ve got a six-person team and a two-week sprint:
| Person | Working days | Hours/day | PTO | Meeting tax | Available |
|---|---|---|---|---|---|
| Ana | 10 | 6 | 0 | 8 hrs | 52 hrs |
| Ben | 10 | 6 | 2 days | 8 hrs | 40 hrs |
| Cara | 10 | 6 | 0 | 12 hrs (on-call) | 48 hrs |
| Dev | 8 (joins late) | 6 | 0 | 8 hrs | 40 hrs |
| Eli | 10 | 6 | 0 | 8 hrs | 52 hrs |
| Fran | 10 | 6 | 1 day | 8 hrs | 46 hrs |
Add it up and your “six people, two weeks” sprint isn’t 480 hours of theoretical time — it’s 278 hours of actual available time. That’s the number you plan against. If you’d assigned work to the 480 figure, you’d have over-committed by 40% before the sprint even began. (For the full breakdown of how that math works, see how to calculate team capacity for a sprint.)
The catch with vanilla Jira is that it doesn’t show you this. Jira tracks story points and a sprint burndown, but it has no concept of Ana’s PTO or Cara’s on-call rotation. So most teams maintain a separate capacity spreadsheet — which someone forgets to update — and eyeball the comparison. That gap is exactly the problem Ekko was built to close: it pulls your real sprint dates, subtracts time off and overhead per person, and shows available-versus-assigned right next to the plan, recalculating live as you reassign. No spreadsheet, no second tab.
Step 6: Start the sprint
Once the work fits the capacity and everyone knows what they own, hit Start sprint. Jira asks you to confirm the dates and goal, then moves everything into the active sprint and kicks off the burndown chart.
That’s it. The board switches to the active sprint view, and your team has a clear, bounded set of work with names attached.
A quick sanity checklist
Before you click start, run through this:
- Sprint goal is written down and everyone can say it back to you
- Every committed story is estimated
- Total committed work is around 80% of real capacity, not 100%
- Each person’s load fits their actual available time (PTO and overhead subtracted)
- Dependencies and carry-over are accounted for
- No story is sitting there blocked by an open question
If you can tick all six, you’re in good shape. If you can’t, the fix is almost always more refinement — not a longer meeting.
The thing nobody tells you
Good sprint planning is mostly about subtraction. Subtracting unready work. Subtracting unavailable hours. Subtracting the optimism that makes us all commit to more than we can do. Get honest about capacity, refine before you plan, and protect that 20% buffer, and the meeting that everyone dreads turns into a 40-minute formality.
That’s the goal, anyway. Plan less, finish what you planned, and let the burndown tell a boring story for once.
Frequently asked questions
- How long should sprint planning take?
- The Scrum Guide caps sprint planning at eight hours for a month-long sprint, and proportionally less for shorter ones; Atlassian suggests roughly an hour per week of sprint length, so about two hours for a two-week sprint. In practice, well-run teams with a groomed backlog often finish faster. If planning regularly eats your whole morning, the real problem is usually upstream: a backlog that wasn't refined before the meeting started.
- Should I assign every task during sprint planning?
- You don't have to, and some teams deliberately leave items unassigned so they get pulled by whoever frees up first. But assigning at least the first few days of work per person makes capacity real instead of theoretical. If you can't name an owner, that's often a sign the story isn't ready.
- What's the difference between sprint planning and backlog refinement?
- Refinement (or grooming) is the ongoing work of getting stories ready: clarifying scope, adding acceptance criteria, and estimating. Sprint planning is the single meeting where you commit a set of already-ready stories to the next sprint. Refinement feeds planning. If you refine continuously, planning becomes a quick selection exercise.
- Can you plan a sprint in Jira without a Scrum board?
- Not really — sprints are a Scrum-board feature in Jira. Kanban boards use continuous flow and don't have sprints. If you're on a Kanban board and want sprints, you'll need to create a Scrum board against the same project or switch the board type.