4.2 Sprint Planning Event

4.2 Sprint Planning Event

Quick Answer: Sprint Planning initiates the Sprint by establishing why the Sprint is valuable (Sprint Goal), what work can be completed (PBI selection), and how that work will be achieved (technical decomposition into the Sprint Backlog). It is timeboxed to a maximum of 8 hours for a one-month Sprint (typically 4 hours for a 2-week Sprint). The Product Owner proposes priorities, but ONLY the Developers decide how many Product Backlog items to select for the Sprint based on their capacity and past performance.

Sprint Planning is the formal event that sets the direction and focus for the entire Sprint. It brings together all three Scrum roles to align business value, team capacity, and technical execution into a coherent commitment called the Sprint Backlog.

---

Purpose and Timebox of Sprint Planning

Sprint Planning addresses the work to be performed during the Sprint. The event is collaborative, interactive, and strictly timeboxed.

Timebox Guidelines

• Maximum 8 Hours: For a full one-month Sprint, Sprint Planning is capped at 8 hours.
• Proportional Scaling: For shorter Sprints, the event is proportionately shorter. A standard 2-week Sprint usually requires no more than 4 hours of Sprint Planning, while a 1-week Sprint typically takes 2 hours.
• Efficiency: The timebox is a maximum limit, not a target. If the team achieves its planning objectives in less time, the event ends early.

Attendance and Roles

All members of the Scrum Team must participate:

• Product Owner: Defines the Sprint objective, presents refined Product Backlog items, and clarifies business context and customer value.
• Developers: Evaluate capacity, select Product Backlog items, decompose items into technical tasks, and estimate execution effort.
• Scrum Master: Facilitates the event, ensures it stays within the timebox, verifies that the team establishes a valid Sprint Goal, and coaches participants on empirical planning.
• External Guests: The Scrum Team may invite external subject matter experts (such as enterprise architects, compliance specialists, or UX designers) to provide technical or domain advice. However, external guests do not vote on or dictate planning outcomes.

---

The Three Topics of Sprint Planning

The 2020 Scrum Guide structures Sprint Planning into three distinct, sequential topics:

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 craft a Sprint Goal that articulates why the Sprint is valuable to stakeholders.

• The Sprint Goal must be finalized before Sprint Planning concludes.
• It serves as the team's North Star throughout execution, providing a shared purpose that transcends individual tasks.

Topic 2: What can be Done this Sprint?

Through discussion with the Product Owner, the Developers select items from the top of the Product Backlog to include in the current Sprint.

• Selection Criteria: Developers evaluate their historical velocity, upcoming capacity (accounting for team member vacations, holidays, and maintenance tasks), the state of Product Backlog refinement, and their Definition of Done.
• Sole Authority (Pull System): Only the Developers determine how many items to pull into the Sprint. Neither the Product Owner, Scrum Master, nor management can force or push work onto Developers. This self-managing boundary prevents burnout and ensures realistic commitments.

Topic 3: How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the technical work necessary to create an Increment that meets the Definition of Done.

• Decomposition: Developers break down selected items into smaller, actionable technical tasks (often estimated in hours or ideal time, typically lasting 1 day or less per task).
• Ownership: How work is decomposed and executed is at the sole discretion of the Developers. No manager or architect assigns individual tasks; Developers self-organize to claim and pair on tasks during execution.
• The Sprint Backlog Output: The combination of the Sprint Goal, the selected Product Backlog items, and the plan for delivering them (tasks) constitutes the official Sprint Backlog.

---

Summary of Sprint Planning Topics

---

Critical CSM Exam Traps in Sprint Planning

1. The Product Owner Assigns Work: False! The Product Owner orders the Product Backlog by value, but ONLY the Developers decide how many items to pull into the Sprint.
2. The Scrum Master Creates the Schedule: False! The Scrum Master facilitates the event, but does not estimate work, assign tasks, or create gantt charts.
3. Sprint Planning Requires 100% Task Decomposition Upfront: False! Developers must design enough of the plan to confidently start the Sprint (often decomposing the first few days of work in detail), while remaining tasks can emerge and decompose during execution.
4. Skipping Topic 1 (No Sprint Goal): False! A Sprint without a clear Sprint Goal is merely a feature factory executing random tickets without strategic focus.

---

Real-World CSM Scenario & Coaching Strategy

Scenario: During Sprint Planning for a 2-week Sprint, the Product Owner presents 12 high-priority user stories. Based on past performance and upcoming team leave, the Developers calculate they only have capacity to reliably complete 7 stories. The Product Owner becomes frustrated, stating that management promised client delivery of all 12 items by the end of the month, and insists the team accept all 12 items.

CSM Coaching Approach:

1. Reinforce Autonomous Selection: The Scrum Master intervenes firmly to uphold Scrum principles, reminding the Product Owner and team that Developers have sole authority to select items based on empirical capacity.
2. Highlight the Risk of Over-Commitment: Explain that forcing 12 items into the Sprint leads to half-finished code, missed quality standards (compromised Definition of Done), burnout, and zero completed Increments.
3. Facilitate Value Optimization: Guide the Product Owner and Developers to collaborate on trade-offs. Can the team select 7 core stories that fully satisfy the Sprint Goal, while deferring the remaining 5 stories to future Sprints?
4. Protect Empirical Forecasting: Ensure management understands that velocity and capacity are empirical data points, not arbitrary targets to be inflated by executive pressure.