3.2 Sprint Planning Event (Three Topics)

3.2 Sprint Planning Event (Three Topics)

Sprint Planning initiates the Sprint by laying out the work to be performed for the upcoming timebox. It is a collaborative event involving the entire Scrum Team: the Product Owner, the Developers, and the Scrum Master. The event is timeboxed to a maximum of 8 hours for a one-month Sprint. For shorter Sprints, the event is usually shorter (e.g., typically 4 hours or less for a two-week Sprint).

---

The Three Topics of Sprint Planning

The 2020 Scrum Guide structures Sprint Planning into three distinct topics that must be systematically addressed by the Scrum Team.

+-----------------------------------------------------------------------------------+
|                              SPRINT PLANNING TOPICS                               |
|                                                                                   |
|  TOPIC 1: WHY IS THIS SPRINT VALUABLE?                                            |
|  - Product Owner proposes value objective                                         |
|  - Scrum Team crafts and commits to the SPRINT GOAL                               |
|                                                                                   |
|  TOPIC 2: WHAT CAN BE DONE THIS SPRINT?                                           |
|  - Developers inspect Product Backlog                                             |
|  - Developers evaluate past performance, capacity & Definition of Done            |
|  - Developers select Product Backlog Items (PBIs)                                 |
|                                                                                   |
|  TOPIC 3: HOW WILL THE CHOSEN WORK GET DONE?                                      |
|  - Developers plan technical implementation                                       |
|  - Work is decomposed into actionable items (e.g., 1-day tasks)                   |
+-----------------------------------------------------------------------------------+

Topic 1: Why is this Sprint Valuable?

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The entire Scrum Team then collaborates to define a Sprint Goal that clarifies why the Sprint is valuable to stakeholders.

• The Sprint Goal is the single objective for the Sprint. It creates clarity, focus, and alignment, encouraging the Developers to work together rather than on isolated, disconnected initiatives.
• The Sprint Goal must be finalized before Sprint Planning concludes. It serves as a fixed commitment for the Developers during the Sprint.

Topic 2: 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 the session to increase understanding and confidence.

• Developer Autonomy: Selecting how many items to bring into the Sprint is the sole responsibility of the Developers. Neither the Product Owner, Scrum Master, nor external management can force work onto the Developers.
• Input Factors for Selection: To determine what can be done, Developers evaluate:
  • Their past performance and historical throughput (velocity).
  • Their upcoming capacity (e.g., team availability, holidays, planned leave).
  • The current Definition of Done.
  • The state of the Product Backlog items (whether they are sufficiently refined).

Topic 3: 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. How this is accomplished is at the sole discretion of the Developers.

• Developers design the system architecture, technical approach, and execution strategy.
• Selected Product Backlog items are frequently decomposed into smaller operational tasks (often work items estimated at one day or less).
• Nobody assigns tasks to Developers; individual Developers pull work autonomously as needed during the Sprint.

---

Inviting External Advisors

While Sprint Planning requires the entire Scrum Team, the Scrum Team may also invite other people (domain experts, technical specialists, or business stakeholders) to attend Sprint Planning to provide technical, business, or domain advice. However, these external advisors do not select backlog items, estimate Developer capacity, or dictate team commitments.

---

The Output: The Sprint Backlog

The ultimate output of Sprint Planning is the Sprint Backlog. The Sprint Backlog is a highly visible, real-time plan owned exclusively by the Developers. It consists of three essential elements:

1. The Sprint Goal (Why)
2. The set of Product Backlog items selected for the Sprint (What)
3. An actionable plan for delivering the Increment (How)

---

Roles and Responsibilities Summary

• Product Owner: Presents business priorities, explains Product Backlog items, proposes the value objective, and helps clarify scope tradeoffs.
• Developers: Select the volume of work they can accomplish, craft the technical execution plan, and commit to the Sprint Goal.
• Scrum Master: Ensures that the event takes place, that attendees understand its purpose, that the event stays within the 8-hour timebox, and acts as a facilitator.

---

PSM I Exam Traps & Empirical Guidance

Exam Trap 1: "The Product Owner assigns 10 user stories to the Developers based on management's quarterly delivery schedule."

Scrum Truth: This is a severe anti-pattern. Only Developers can select items from the Product Backlog, as they are accountable for managing their own capacity and delivering a Done Increment.

Exam Trap 2: "Sprint Planning cannot finish until every single task for the entire 4-week Sprint is fully detailed and assigned to individual engineers."

Scrum Truth: Sprint Planning requires only enough detailed decomposition for the Developers to get started (e.g., the first few days of work). Deeper technical tasking occurs continuously during the Sprint as Developers learn more.