Sprint planning goes wrong in a predictable place, and it is almost never during the meeting. It goes wrong the week before, when nobody refined the backlog. Fix that one thing and planning shrinks from a draining two-hour ordeal into a calm twenty minutes.
So this is a checklist you can actually run, not a philosophy. Here it is first, then the reasoning behind each step.
The sprint planning checklist
Run planning in this order and it tends to stay short:
- Confirm the backlog was refined and ordered before the meeting started.
- Agree on a one-sentence sprint goal so the work has a shape.
- Let the team pull stories until it has a realistic commitment, using past sprints as a guide.
- Put every committed story on the board before anyone leaves the room.
- Keep a little capacity in reserve for the interruptions you already know are coming.
That is the whole meeting. The rest of this explains why each step matters and shows what the output looks like.
Those five steps are also your agenda
Read them again and you have a meeting agenda. Run them in order, timebox each, and the session paces itself: a few minutes confirming the backlog is ready, a few setting the goal, the bulk of the time pulling work, a final check that the board matches the plan. If you want a copy-paste agenda for the calendar invite, it is those five lines and nothing else.
Do the real work before the meeting
The single biggest reason planning drags is a backlog that was not ready. If the team is seeing stories for the first time during planning, you are not planning, you are refining under time pressure, and everyone can feel it.
Refine earlier in the sprint, in a short separate session or as an ongoing habit, so that by the time planning starts the top of the backlog is already:
- Clear. Each story says what needs to happen and why, in language anyone on the team can read without a translator.
- Estimated. The team has a rough sense of size, even if it is only small, medium or large.
- Ordered. The product owner has put the items in priority order, so nobody debates what comes first.
Walk in with that and planning is a quick, confident exercise. Walk in without it and you are running an archaeology dig with a two-hour deadline.
Start with the goal, not the stories
Before anyone pulls a single story, write one sentence: what is this sprint for? A goal gives the work a shape and tells you what to cut when the week goes sideways.
Make it specific and outcome-shaped. "Ship the new onboarding flow so a new user reaches their first board without help" is a goal. "Do some onboarding tickets" is a to-do list. Without a goal, a sprint is a pile of unrelated tasks, and a pile has no way to tell you what matters when reality intervenes.
Let the team pull the work
This is the part that separates planning that works from planning that grinds. The product owner owns the priority order. The team owns how much it commits to. Two different jobs, and blurring them is where planning goes wrong.
Go down the ordered backlog and let the team pull stories in until it honestly believes it has enough, using recent sprints as the yardstick. If your team has finished around 20 points in each of the last three sprints, then 20 is your honest number, not the 28 someone is quietly hoping for. A sprint that is over-committed on day one is a sprint that ends in an apology.
What a healthy plan looks like
Here is the output of a calm two-week planning session for a small team:
- Sprint goal: new users can sign up and reach their first board with zero help.
- Recent velocity: roughly 20 points per sprint.
- Committed: onboarding email (5), empty-state board template (8), guided first-board tour (5). Eighteen points.
- Held back: a 5-point analytics dashboard that does not serve the goal. It stays at the top of the backlog for next time.
- Reserve: about 2 points of slack left deliberately unfilled.
Notice the team committed to 18 against a velocity of 20, left the off-goal item alone, and kept a little room. That is a plan that survives contact with a real week.
Make the plan visible before anyone leaves
By the end of planning, the sprint should already exist on the board, every committed story sitting in the first column, ready to go. If your tool makes you assemble that view afterward, the plan lives in someone's notes instead of in front of the whole team.
In Scrumpy, planning the sprint and seeing it laid out on the board are the same action, not two, and stakeholders can follow the plan on a free view-only seat without taking up a paid one. The plan only stays honest if the whole board fits on one screen, which is why we are so stubborn about never pushing columns off the edge.
Leave room on purpose
Do not pack the sprint to the brim. Real weeks contain support fires, sick days and the bug nobody saw coming. A little slack is not slack in the lazy sense; it is the margin that lets a plan bend on Tuesday instead of breaking. Run the five steps, keep the reserve, and start your next sprint as the short, calm meeting it was always supposed to be.
Frequently asked questions
What should a sprint planning checklist include?
Confirm the backlog was refined and ordered, agree on a one-sentence sprint goal, let the team pull stories until it has a realistic commitment, make sure every committed story is on the board, and keep a little capacity in reserve.
How long should sprint planning take?
A good rule of thumb is up to two hours for a two-week sprint, and less as your team gets better at it. If planning regularly runs longer, it usually means the backlog was not refined beforehand.
What should you do before sprint planning?
Refine the backlog ahead of time. Make sure the top items are clear, estimated and ordered by priority, so planning is about committing to work rather than discovering it for the first time.
Who should attend sprint planning?
The whole delivery team plus the product owner. The product owner brings priorities and answers questions about the why, and the team decides how much it can realistically commit to.
