The sprint planning meeting, step by step

Sprint planning is the meeting that opens a sprint. In it, the team agrees a sprint goal and decides how much of the backlog it can realistically finish — turning a prioritised list into a plan the team actually believes. A backlog is a wish list until someone decides what gets built next. That decision is sprint planning.

Done well, it takes an hour or two and the team leaves knowing what it is doing and why. Done badly, it becomes a backlog-reading session where the product owner assigns tickets and everyone nods — and the “commitment” quietly falls apart by Wednesday.

Why, what, and how

The Scrum Guide frames sprint planning around three questions, and they are worth keeping in this order:

• Why is this sprint valuable? The answer is the sprint goal — one sentence the whole team can rally behind. Agree it before you touch the backlog. Setting a sprint goal is its own skill.
• What can be done this sprint? The developers pull items from the top of the backlog that serve the goal, until they hit the edge of their capacity. This is a forecast, not a promise extracted under oath.
• How will the chosen work get done? The team breaks the top items into enough of a plan to start — tasks, an approach, the obvious risks. Not every item to the last subtask; enough to begin with confidence.

The output is a sprint backlog: the goal, the selected items, and the plan for delivering them.

Scope first, then plan

The single most useful structural habit is to run planning in two distinct passes rather than one blurry one.

Part one is scope. The product owner presents the goal and the candidate items in priority order. The team asks clarifying questions, checks each item against the definition of ready, and pulls work until capacity runs out. Stop there. The temptation to squeeze in “just one more” small story is exactly how sprints overcommit.

Part two is plan. Now the team goes deep on the items it selected — decomposing them into tasks, spotting dependencies, agreeing who picks up what first. This is where you find the story that looked like a 3 and is actually a week of work hiding behind a vague acceptance criterion.

Keeping the two apart stops the meeting from thrashing between “should we take this?” and “how would we build it?” on every single item.

What you need in the room

Sprint planning only works if its inputs arrive ready. The meeting converts inputs into a plan; it does not manufacture them on the spot.

• A refined, prioritised backlog. The top items should already be understood and roughly sized. If planning is the first time the team sees a story, you are doing backlog refinement in the wrong meeting — and it will run long. Refinement is the feeder; planning is the decision.
• A real capacity number. Not “two weeks times the team size”, but the hours actually available after leave, meetings, support rotations, and the interrupt tax. See velocity and capacity planning.
• The whole team. The developers make the forecast, so the developers have to be there. Planning by proxy produces commitments nobody owns.

Who runs it

The Scrum Master facilitates — protects the timebox, keeps the two passes separate, and stops the meeting sliding into solutioning every edge case. The product owner brings the goal and the ordered backlog, and answers “why” and “what” questions on the spot. The developers decide how much they take on and how they will build it.

That last point matters: the forecast belongs to the people doing the work. A plan handed down and accepted in silence is not a commitment — it is a queue.

How long it should take

The Scrum Guide timeboxes planning at up to eight hours for a one-month sprint, and proportionally less for shorter ones — so roughly two hours per week of sprint. A two-week sprint should land around four hours, often less once a team has a steady cadence.

Treat that as a ceiling, not a target. Teams that reliably need the full timebox are almost always refining during planning. Fix the input, and the meeting shortens on its own. If you want a minute-by-minute breakdown, the sprint planning agenda chapter lays one out.

Where it goes wrong

Three failure modes account for most bad planning meetings.

The reading session. The product owner narrates tickets and the team listens. No decision gets made because no one is deciding — they are being briefed. Planning should feel like the team choosing, not being assigned.

The overcommit. Capacity gets treated as a stretch goal. The team pulls its best-ever velocity as a floor and adds a little for ambition. Then a support fire, a sick day, and one under-estimated story turn the sprint into a scramble. Plan with the humble number, not the heroic one.

Planning without a goal. The team selects a grab-bag of unrelated tickets, and when the sprint gets tight there is no principle for what to drop — so everything slips a little and nothing ships clean. The goal is what tells you which tickets to abandon under pressure.

Get the inputs ready, keep scope and plan apart, and let the team own the forecast. The rest of this guide goes deep on each piece — start with the agenda or grab the sprint planning template.

Frequently asked questions

What is sprint planning?

Sprint planning is the Scrum event that opens a sprint. The team agrees a sprint goal, selects the backlog items it forecasts it can finish, and sketches how the work will get done. It answers three questions — why the sprint is valuable, what will be built, and how.

How long should sprint planning take?

Timebox it to about two hours per week of sprint — so roughly two hours for a one-week sprint, four for a two-week sprint, up to eight for a month. That is a ceiling, not a target. If you consistently need the full timebox, the backlog usually was not ready going in.

What are the key steps in sprint planning?

Confirm the team’s real capacity for the sprint; agree a sprint goal; pull backlog items that serve that goal until you reach capacity; break the top items into a workable plan; and confirm the team believes the forecast. Scope first, then plan — in that order.

Who runs sprint planning?

The Scrum Master facilitates and keeps it timeboxed. The product owner brings a prioritised, refined backlog and explains the why. The developers decide how much they can take on and how they will build it — the forecast is theirs to make, not the product owner’s to assign.