Sprint Planning initiates the Sprint by laying out the work to be performed. The whole Scrum Team collaborates on the plan, and the Product Owner ensures attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may 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.
Topic One, why is this Sprint valuable?
The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalised before Sprint Planning ends.
The Product Owner proposes rather than dictates, and the goal is defined by the whole team, which is what makes it something the Developers own. A goal handed down complete is a target somebody else set, and a team has little reason to protect it when the work turns out hard. The Sprint Goal is also a single objective rather than a summary of the items chosen, which is what the Developers protect when scope is renegotiated mid Sprint.
Topic Two, what can be Done this Sprint?
In discussion with the Product Owner, the Developers select items from the Product Backlog to include in the Sprint. The Scrum Team may refine these items during the process, which increases understanding and confidence. Selecting how much can be completed is often challenging, and the more the Developers know about their past performance, upcoming capacity and 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 people who will do the work can judge how much of it fits, so an amount set by anyone 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.
Topic Three, how will the chosen work get done?
For each selected item, the Developers plan the work needed to create an Increment that meets the Definition of Done. This is often done by decomposing items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers, and 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. Leaving with the first days planned in detail and the rest sketched is consistent with the framework, because the Sprint Backlog changes daily as more is learned.
The 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 rather than a target, and a team that reliably needs all of it is paying inside the event for something that should have happened before it.
What makes planning short is refinement, which is ongoing work spread across the Sprint rather than an event of its own. A team arriving with items already understood spends the event deciding, and a team arriving cold spends it working out what the items mean before committing to them anyway.
What has to be ready before the event
Two things genuinely make the event work, and the exam surrounds them with substitutes that sound more responsible.
The first is a Product Goal the Product Owner has developed and explicitly communicated, so the Sprint has a direction to serve. Without one the team can still select items and still fill a Sprint, and the question of why this Sprint rather than some other has no answer beyond whatever happened to sit at the top of the list.
The second is a Product Backlog whose most important items are ready for discussion. Ready means refined enough to be talked about and selected, not specified down to the last field. The Guide asks the Product Owner to ensure attendees are prepared to discuss the most important items, which is a bar about shared understanding rather than about documentation.
Everything else on the plausible list is either optional or actively harmful.
Refining the whole Product Backlog is not a precondition, it is waste. 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 worse than unnecessary. 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, and a team waiting on a signature has an organisational constraint rather than a Scrum requirement.
An agreed cadence for the Daily Scrum is useful, and the Guide does ask for the same time and place every working day. It is still not a precondition for planning, because it can be settled at any point once the Sprint is running.
The output
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 the Guide is explicit about the timing of. 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. What is meant to survive the Sprint unchanged is the Sprint Goal.