4.2 Sprint Planning

Purpose and Timebox

Sprint Planning initiates the Sprint by laying out the work to be performed. The resulting plan is created by the collaborative work of the entire Scrum Team — Product Owner, Scrum Master, and Developers together. Planning is not handed down to the Developers; it is built with them.

Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints the event is usually shorter — roughly four hours for a two-week Sprint, two hours for a one-week Sprint, though these are conventions, not Guide-mandated figures. The only fixed numbers the Guide states are the maximums for a one-month Sprint. Remember: a timebox is a maximum, not a target. If the team produces a sound Sprint Goal and Sprint Backlog in three hours, the event ends.

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 also invite other people to attend to provide advice — domain experts, designers, or stakeholders — but those guests advise; they do not decide. The Scrum Master's job is to ensure the event happens, is positive and productive, and stays within the timebox; the Scrum Master does not assign work or own the plan.

The Three Topics: Why, What, How

Sprint Planning addresses three topics in order. A reliable mnemonic is Why, What, How.

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 finalized before Sprint Planning ends — a Sprint cannot legitimately begin without one. Note that the Product Owner proposes value but the whole team crafts the Sprint Goal; a question stating that the Product Owner alone writes the Sprint Goal is a distractor.

Topic Two — What can be Done this Sprint?

Through 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 this process, increasing understanding and confidence. Forecasting how much can be completed is hard; the more the Developers know about past performance, capacity, and the Definition of Done, the more confident the forecast. Crucially, the Developers decide how many items to take on — not the Product Owner, not management, and not a velocity formula imposed by the Scrum Master.

Topic Three — How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work needed to create an Increment that meets the Definition of Done. This often means decomposing items into smaller work items of one day or less, but the level of detail is left to the Developers' sole discretion. No one outside the Developers tells them how to turn Product Backlog items into Increments of value. On the exam, any answer where the Scrum Master, Product Owner, or a manager dictates how the work is broken down is wrong.

Outputs of Sprint Planning

Sprint Planning produces the Sprint's plan, captured in two artifacts:

• The Sprint Goal — the single objective for the Sprint, the why.
• The Sprint Backlog — composed of three things together: the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how).

A pervasive misconception treats the Sprint Backlog as only the list of selected items. In the 2020 Scrum Guide the Sprint Backlog is Why + What + How — goal, items, and plan. The Product Goal is not an output of Sprint Planning; it lives in the Product Backlog and persists across Sprints. If a question lists "the Product Goal" or "a signed scope contract" as a Sprint Planning output, reject it.

Refinement Versus Planning

A recurring source of confusion is the line between Product Backlog refinement and Sprint Planning. Refinement is the ongoing activity of breaking down and further defining Product Backlog items into smaller, more precise items; it is not a formal Scrum event and has no timebox. Sprint Planning, by contrast, is one of the five events and is timeboxed. Well-refined items entering Planning make the What topic faster and the How topic more reliable, because the Developers already understand the items.

On the exam, treat "refinement" as continuous work that can happen any time during the Sprint, and "Sprint Planning" as the bounded event that opens each Sprint. A question that calls refinement "a mandatory event before Sprint Planning" is wrong — it is an activity, not an event.

The Sprint Goal Gives Planning Coherence

The Sprint Goal is what makes the selected items a coherent Sprint rather than a random batch of tasks. Because the Sprint Goal is a commitment for the Sprint Backlog, it creates flexibility in the exact items: if the Developers learn something mid-Sprint, they can adjust which items they finish as long as the Sprint Goal is still met. This is why finalizing the Sprint Goal before Planning ends is non-negotiable — without it, the Sprint Backlog has no anchor, the Daily Scrum has nothing to inspect progress against, and the Sprint Review has no clear outcome to discuss.

" That is a defect: every Sprint has exactly one Sprint Goal, set during Planning by the whole Scrum Team.