4.2 Sprint Planning

4.2 Sprint Planning

Scrum Guide 2020: Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

PSPO I tests whether you treat Sprint Planning as a shared design of value for one Sprint, not a ceremony where the Product Owner hands a task list to Developers or a project manager assigns hours. The event produces a Sprint Backlog: the Sprint Goal, the Product Backlog items selected for the Sprint, and the plan for delivering them.

---

Who Attends and Who Prepares

Sprint Planning is work of the entire Scrum Team—Product Owner, Scrum Master, and Developers. The Product Owner ensures attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. That preparation is part of effective Product Backlog management: ordered, understood items and a clear longer-term Product Goal so the team is not inventing strategy from a blank whiteboard.

The Scrum Team may also invite other people to attend Sprint Planning to provide advice (for example, a domain expert or a specialist for a particular item). Invitees advise; they do not become a second Product Owner or a steering committee that overrides the team’s plan.

Timebox: Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The timebox forces focus: Planning produces a usable Sprint Backlog, not a perfect multi-month design.

---

Three Topics (Know the Order and Ownership)

The Guide structures Sprint Planning around three topics. Exam questions often mix up who proposes, who selects, and who plans 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 prior to the end of Sprint Planning.

Key distinctions:

• The PO does not unilaterally dictate a Goal that the team never discusses.
• The team does not skip “why” and jump straight to a feature shopping list.
• The Sprint Goal is a single coherent objective for the Sprint, not a dump of unrelated tickets labeled “Goal.”
• Finalizing the Goal before Planning ends means you leave the event with a committed why—not a vague aspiration to “figure out the Goal mid-Sprint.”

As Product Owner, your craft in Topic One is connecting Product Goal → this Sprint’s value hypothesis → Sprint Goal language stakeholders can understand.

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 current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

Selecting how much can be completed within a Sprint may be challenging. However, 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 Sprint forecasts.

Implications:

• Selection is not “the PO assigns story points and Developers obey.”
• Selection is not “stakeholders pick tickets in the meeting.”
• Developers forecast based on empiricism (what has happened, capacity, Done), not wishful packing of every request.
• Refinement during Planning is allowed and useful; it is not a sign that Planning failed—provided the team still exits with a coherent Goal and a realistic set of items.

Your PO role in Topic Two is clarity of intent, availability for questions, and honest trade-offs when capacity cannot hold every desired item without endangering the Sprint Goal or quality.

Topic Three: How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

Exam traps:

• Product Owner writing task breakdowns and assigning owners.
• Scrum Master prescribing the technical plan.
• Managers inserting a work-breakdown structure that Developers must follow.

You may clarify what “valuable and Done” means; you do not own the how of implementation. That boundary protects self-management and keeps the PO focused on value outcomes.

---

The Result: Sprint Backlog

The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

The Sprint Backlog is owned as a plan by the Developers and is highly visible and real-time. It is updated throughout the Sprint as more is learned—especially via Daily Scrum—without requiring a new formal Sprint Planning event every day.

---

Product Owner Behaviors That Help Planning Succeed

• Arrive prepared: important PBIs are ordered, understood enough to discuss, and mapped to the Product Goal.
• Propose value, co-create the Goal: bring a clear value hypothesis; collaborate so the Sprint Goal is shared, not imposed as theater.
• Stay for the whole event: Planning is not “PO speaks for ten minutes and leaves.” Topics Two and Three still need your clarification even though Developers select and plan how.
• Negotiate scope against capacity and Done: when forecasts cannot hold everything, re-order or de-scope with the Goal in mind rather than pressuring quality down.
• Invite advice carefully: specialists may attend to advise; they do not seize ordering authority.
• Protect the three-topic integrity: do not skip “why,” do not smuggle a year-long roadmap commitment into one Planning, and do not convert Topic Three into your personal task board.

---

Common Exam Anti-Patterns

1. PO-only Planning — Developers receive a sealed bag of tickets; no collaboration on the Sprint Goal.
2. Commitment theater — Forced acceptance of more items than capacity and Done allow, “because the release date is fixed.”
3. How dictated by PO or managers — Task assignments and technical design imposed on Developers.
4. Goal deferred — “We’ll invent the Sprint Goal later this week.” The Guide requires the Goal finalized before Planning ends.
5. Stakeholders vote the Sprint contents — Selection remains a Developer conversation with the Product Owner, not a committee ballot.
6. Eight hours treated as a minimum — It is a maximum for a one-month Sprint; shorter Sprints usually plan in less time.

---

Link to Empiricism and the Wider Sprint

Sprint Planning creates the initial forecast for the Sprint. It does not freeze learning. During the Sprint, scope may still be clarified and renegotiated with the Product Owner as long as the Sprint Goal is not endangered and quality does not decrease. Daily Scrums adapt the plan for the next day. Sprint Review inspects the Increment and Product Backlog; the Retrospective improves effectiveness. Planning is the start of the empirical loop for this container, not a contract that forbids adaptation.

Forecast tools (velocity history, capacity math, burn charts) can inform Topic Two confidence. They still do not replace empiricism: past performance and Done are better guides than optimistic promises.

---

PSPO Scenario Drill

Scenario: A Product Owner enters Planning with twenty “must-have” items and a pre-written Sprint Goal. Stakeholders demand all twenty. Developers, looking at capacity and Done, believe eight items support a coherent Goal. The PO insists Developers must take all twenty and that the PO will assign tasks by component.

Sound approach: Re-open Topic One so the whole team defines a Sprint Goal that is valuable and achievable. In Topic Two, Developers select what can be Done with the PO’s collaboration—likely fewer items aligned to that Goal. In Topic Three, Developers alone plan how. The PO negotiates order and scope, does not dictate tasking, and does not lower quality to force volume. The Sprint Backlog that leaves Planning is Goal + selected items + Developers’ plan—not a stakeholder wish list.

Master that scene and you have the Sprint Planning accountabilities PSPO I expects.