Sprint Planning initiates the Sprint by laying out the work to be performed, and the plan that comes out of it is created by the whole Scrum Team working together. Before the event the Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how those items map to the Product Goal. The Scrum Team may also invite others to attend to provide advice.
The word advice is exact. An invited specialist or stakeholder informs the team's decisions and makes none of them, so nobody outside the Scrum Team selects the work, sets the goal or approves the plan.
Why this Sprint is valuable
Topic One of Sprint Planning settles the Sprint Goal. The Product Owner proposes how the product could increase its value and utility in the current Sprint, and the whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Scrum Team must finalise that Sprint Goal before Sprint Planning ends.
The verb for the Product Owner is proposes, and the verb for the Scrum Team is defines. That division is what makes the Sprint Goal something the Developers own, because a goal handed to them complete is a target somebody else set, and a team has little reason to protect a target when the work turns out hard. The Sprint Goal is also a single objective rather than a summary of the items chosen, and that objective is what the Developers hold to when scope is renegotiated mid Sprint.
What can be Done this Sprint
Topic Two produces the selection. In discussion with the Product Owner, the Developers select items from the Product Backlog to include in the Sprint, and the Scrum Team may refine those items during the event, which increases understanding and confidence. Selecting how much can be completed is often challenging, and the more the Developers know about their past performance, their upcoming capacity and their Definition of Done, the more confident they will be in their forecast.
The selection belongs to the Developers and to nobody else. The Product Owner is in the conversation throughout and may explain, argue and reorder, and may not assign items or set the quantity. Only the Developers can judge how much of the work fits, so an amount set by anybody else is a wish presented as a forecast.
The Definition of Done bounds the discussion, because an item is a candidate only if the team can bring it to that standard inside the Sprint.
How the chosen work gets done
Topic Three turns the selection into a plan. For each selected item, the Developers plan the work needed to create an Increment that meets the Definition of Done, which is often done by decomposing items into smaller work items of one day or less. The Developers have sole discretion over how, and the Guide adds that no one else tells them how to turn Product Backlog items into Increments of value.
The one day figure is a suggestion, and how much of the plan exists when the event ends is for the Developers to settle. A team may leave with the first days planned in detail and the rest sketched, which is consistent with the framework, because the Sprint Backlog changes daily as the Developers learn more.
The Sprint Planning timebox
Sprint Planning is timeboxed to a maximum of eight hours for a one month Sprint, and shorter Sprints usually have shorter events. Eight hours is a ceiling, so a team that reliably needs all of it is paying inside the event for work that should have happened before it.
What makes planning short is refinement, which runs continuously through the Sprint and is not an event of its own. A team that arrives with the top items already understood spends the event deciding, while a team that arrives without that understanding spends the event working out what the items mean and then commits to them anyway.
Keeping the event inside its eight hours is the Scrum Master's service to it, alongside ensuring that it happens and that everyone present understands its purpose. The decisions themselves belong elsewhere, so a Scrum Master who writes the Sprint Goal on the board and asks the room to agree has taken the one decision the whole Scrum Team is meant to make together.
What has to be ready before Sprint Planning
Two things genuinely make the event work, and the assessment surrounds them with substitutes that sound more responsible.
One is a Product Goal that the Product Owner has developed and explicitly communicated, which gives the Sprint a direction to serve. Without a Product Goal the team can still select items and still fill a Sprint, and nothing answers the question of why this Sprint holds the work it holds, beyond whatever happened to sit at the top of the list.
The other is a Product Backlog whose most important items are ready for discussion. Ready here means refined enough to be talked about and selected, so it does not mean specified down to the last field. The Guide asks the Product Owner to ensure attendees are prepared to discuss the most important items, and preparedness is a matter of shared understanding, which no amount of documentation supplies on its own.
Everything else on the plausible list is either optional or actively harmful.
Refining the whole Product Backlog is not a precondition, and the effort spent on it is wasted. Most of the list will change before anybody reaches it, so detail added now to items ordered below the next Sprint or two is detail spent on work that may never happen.
A Sprint Goal agreed in advance is actively harmful. The Sprint Goal is crafted during the event by the whole Scrum Team, so arriving with a non negotiable one removes the negotiation the event exists for and leaves the Developers delivering an objective somebody else settled.
Budget approval for each Sprint belongs to a funding model outside Scrum. Nothing in the framework asks for a Sprint to be authorised, so a team waiting on a signature is held up by an organisational constraint that Scrum never asked for.
An agreed cadence for the Daily Scrum is useful, and the Guide does ask for the same time and place every working day. That cadence is still not a precondition for Sprint Planning, because the team can settle it at any point once the Sprint is running.
The output of Sprint Planning
The Sprint Goal, the Product Backlog items selected for the Sprint and the plan for delivering them are together referred to as the Sprint Backlog.
All three have to exist by the end of the event, and the Sprint Goal is the one whose timing the Guide states explicitly. The plan is the part most often mistaken for a deliverable, and it belongs to the Developers, who change it whenever a day's work teaches them something. The Sprint Goal is the one part meant to survive the Sprint unchanged.