Sprint Planning

# CHAPTER 6

Sprint Planning #

1. Introduction #

2. Learning Objectives #

• Identify the purpose, attendees, and timebox of the Sprint Planning event.

• Define a cohesive "Sprint Goal."

• Differentiate between the Product Backlog and the Sprint Backlog.

• Perform capacity planning to avoid over-committing the development team.

• Break down large User Stories into actionable, technical tasks.

3. The Mechanics of the Meeting #

• Attendees: The entire Scrum Team (Product Owner, Scrum Master, Developers).

• Timebox: A maximum of 8 hours for a one-month Sprint. For a two-week Sprint, it is usually timeboxed to 4 hours.

• The Facilitator: The Scrum Master ensures the event takes place and keeps it within the timebox.

4. Topic 1: Why is this Sprint valuable? (The Sprint Goal) #

• What it is: A single, unified objective for the Sprint. (e.g., "Implement secure checkout with Stripe").

• Why it matters: It gives the Developers focus. If they get stuck on a low-priority task mid-sprint, they can look at the Sprint Goal to decide if they should drop the task to ensure the main objective is met.

5. Topic 2: What can be Done this Sprint? (Selection) #

• Capacity Planning: The Developers must estimate their capacity. Are two people on vacation? Is there a public holiday? They calculate how many total hours or "points" they can realistically handle.

• The Negotiation: The PO wants 10 items. The Developers say their capacity only allows for 6. The Developers have the final say on what they pull into the Sprint. No one can force more work onto the Developers.

6. Topic 3: How will the chosen work get done? (The Sprint Backlog) #

• Task Breakdown: A User Story is written in business language (e.g., "As a user, I want to login"). During planning, the Developers break this down into technical tasks (e.g., "Create SQL users table," "Build JWT auth route," "Design frontend form").

• Accountability: Only the Developers design the technical plan. The Product Owner does not tell them *how* to build it.

7. Diagrams/Visual Suggestions #

[ Prioritized Product Backlog ]
             |
             | (1. PO presents priorities)
             v
[ The Negotiation ] <---> [ Developers analyze Capacity ]
             |
             | (2. Define Sprint Goal & Select Items)
             v
[ Selected User Stories ]
             |
             | (3. Developers break stories into Technical Tasks)
             v
[ THE SPRINT BACKLOG ] ===> SPRINT STARTS

8. Best Practices #

• "Ready" State: A major best practice is the "Definition of Ready." A User Story should not be brought into Sprint Planning if it doesn't have clear Acceptance Criteria or is too large to fit in a Sprint. If it isn't "Ready," it stays in the Product Backlog.

9. Common Mistakes #

• The Optimism Trap: Developers are notoriously optimistic. They assume every day will be 8 hours of uninterrupted coding. They forget about company meetings, code reviews, and bathroom breaks. A healthy team plans for roughly 6 hours of productive capacity per developer per day. Over-committing leads to failed Sprints and demoralized teams.

10. Mini Project: Capacity Planning #

1. 1. Developer A is taking 2 days of PTO.

1. 2. Developer B is stuck in mandatory company HR meetings for 1 day.

1. 3. Developer C is available all 10 days.

• Total theoretical days: 30

• Minus PTO/Meetings: 30 - 3 = 27 developer days.

• Assume 6 hours of actual coding per day: 27 * 6 = 162 total hours of capacity for this Sprint. The team cannot commit to tasks exceeding 162 hours.

11. Practice Exercises #

1. 1. Explain the specific purpose of the "Sprint Goal." How does it help a team make decisions halfway through a Sprint if a major bug suddenly appears?

1. 2. Why is the creation of the technical "Task Breakdown" strictly the responsibility of the Developers, rather than the Product Owner?

12. MCQs with Answers #

13. Interview Questions #

• Q: A new team consistently fails to finish the work they commit to during Sprint Planning. As a Scrum Master, what specific metrics or capacity planning concepts would you investigate to fix this?

• Q: Walk me through the structural difference between a User Story in the Product Backlog and a Task in the Sprint Backlog.

• Q: Explain the phrase: "The Sprint Backlog is highly visible, real-time picture of the work that the Developers plan to accomplish." Can the Sprint Backlog be changed mid-sprint?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #