TECH **Sprint Planning (What to Build and How) – Zero-Fluff, Hands-On Guide**

Sprint Planning (What to Build and How) – Zero-Fluff, Hands-On Guide

For Agile & Scrum practitioners who need to run sprints that actually deliver value—without the theory overload.

1. What This Is & Why It Matters

Sprint Planning is the first event of every sprint where your team decides what to build (the Sprint Goal and Product Backlog Items) and how to build it (the Sprint Backlog and task breakdown).

Why it matters in production:
- Without it, teams waste 20–40% of sprint capacity on misaligned work, rework, or "emergency" scope changes.
- Poor planning = missed deadlines, technical debt, and frustrated stakeholders. (Ever seen a team "finish" a sprint but deliver nothing usable? That’s a planning failure.) - Good planning = predictable delivery. You’ll know by Day 1 if the sprint is feasible, and you’ll have a clear path to demo-ready work.

Real-world scenario:
You’re a Scrum Master inheriting a team that’s "doing Agile" but missing sprint goals 80% of the time. Stakeholders are losing trust, and engineers are burned out from constant context-switching. Sprint Planning is your lever to fix this. Done right, it aligns the team, sets realistic expectations, and ensures work is actually valuable—not just "stuff we thought of."

2. Core Concepts & Components

3. Step-by-Step Hands-On: Running a Sprint Planning Meeting

Prerequisites:
- A refined Product Backlog (PBIs are "Ready").
- Historical velocity data (last 3–5 sprints).
- Team capacity (account for PTO, holidays, meetings).
- Stakeholders available (Product Owner + key devs).

Step 1: Set the Stage (5–10 min)

• Goal: Align on the why before the what.
• Script:

  "Last sprint, we delivered [X]. This sprint, the business needs [Y] because [Z]. Our goal is: [Sprint Goal]. Does this make sense?"

  
  

• Example Sprint Goal:

  "Enable users to reset passwords without emailing support."

  
  

Step 2: Review Capacity (5 min)

• Calculate available hours:
• Default: 6 hours/day per dev × 10 days = 60 hours.
• Adjust for:
  • PTO: -8 hours (1 day off).
  • Meetings: -5 hours (daily standup, refinement, retro).
  • Total capacity: 60 - 8 - 5 = 47 hours.
• Tool: Use a spreadsheet or Jira’s capacity planner.

Step 3: Select PBIs (20–30 min)

• Rule: Start with the highest-priority PBI and work down.
• Process:
• Product Owner (PO) presents the top 3–5 PBIs.
• Team asks clarifying questions (e.g., "What’s the expected UX flow for password reset?").
• Team estimates effort (story points or hours).
• Stop when capacity is full (e.g., if capacity = 47 hours and PBIs = 45 hours, stop).
• Example:
  | PBI | Estimate (hours) | Notes | |------------------------------|------------------|--------------------------------| | Password reset UI | 12 | Needs UX mockups | | Backend API for reset | 16 | Depends on auth service | | Email notification service | 10 | Uses SendGrid | | Total | 38 | Buffer: 9 hours (20%) |

Step 4: Break PBIs into Tasks (30–45 min)

• Goal: Ensure every PBI is actionable.
• Task breakdown example (Password Reset UI):
  ```markdown
• [ ] Create Figma mockup (2h)
• [ ] Implement frontend form (4h)
• [ ] Add form validation (2h)
• [ ] Connect to backend API (2h)
• [ ] Write unit tests (2h) ```
• Pro tip: Use INVEST criteria for tasks:
• Independent (can be done in any order).
• Negotiable (not a rigid spec).
• Valuable (contributes to the sprint goal).
• Estimable (you can size it).
• Small (1–2 days max).
• Testable (has clear acceptance criteria).

Step 5: Identify Risks & Dependencies (10 min)

• Ask:
• "What could go wrong?" (e.g., "UX mockups delayed").
• "What do we need from others?" (e.g., "Backend API ready by Day 3").
• Mitigation strategies:
• Dependencies: Assign an owner to chase them before the sprint.
• Risks: Add a spike (e.g., "Research SendGrid API" if unsure).

Step 6: Commit & Confirm (5 min)

• Team says:

  "We commit to delivering [Sprint Goal] by [date] with these PBIs: [list]."

  
  

• PO says:

  "I accept this plan. If scope changes, we’ll renegotiate."

  
  

• Document: Update the Sprint Backlog in Jira/Trello.

4. ? Production-Ready Best Practices

Alignment

• Sprint Goal > PBIs. If a PBI doesn’t contribute to the goal, drop it.
• PO must be available. If they’re absent, planning becomes a guessing game.

Estimation

• Use historical data. If the team averages 30 story points/sprint, don’t commit to 50.
• Buffer for unknowns. Add 20% contingency (e.g., if capacity = 50 hours, commit to 40).

Task Breakdown

• Tasks should be 1–2 days max. If a task is >2 days, split it.
• Avoid "do research" tasks. Instead, use spikes with clear outcomes (e.g., "Produce a decision doc on AWS vs. GCP").

Dependencies

• Flag them early. If a dependency blocks a PBI, don’t commit to it.
• Mock or stub. If the dependency isn’t ready, create a temporary solution (e.g., mock API).

Tools

• Jira: Use the Sprint Planning Board.
• Trello: Create a "Sprint Backlog" list with PBIs and tasks.
• Miro: For remote teams, use a Sprint Planning Template.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical question patterns:
1. "What’s the purpose of Sprint Planning?"
- ❌ "To assign tasks to team members." (Scrum doesn’t assign tasks—teams self-organize.)
- ✅ "To define the Sprint Goal and select PBIs the team can commit to delivering."

1. "Who decides how much work goes into the sprint?"
2. ❌ "The Product Owner." (PO prioritizes, but the team decides capacity.)

3. ✅ "The Development Team, based on their capacity and velocity."

4. "What happens if the team can’t finish all PBIs?"

5. ❌ "They work overtime to finish." (Scrum values sustainable pace.)
6. ✅ "They renegotiate scope with the PO and adjust the Sprint Backlog."

Key trap distinctions:
- Sprint Goal vs. PBIs: The goal is the outcome; PBIs are the outputs.
- Capacity vs. Velocity: Capacity = available hours; velocity = historical delivery rate.
- Spike vs. Task: A spike is research; a task is implementation.

Scenario-based question:

"Your team’s velocity is 30 story points, but the PO wants to commit to 50. What do you do?" - ✅ Answer: "Explain that velocity is a forecast, not a target. Commit to 30–35 points and negotiate scope with the PO."

7. ? Hands-On Challenge

Challenge:
Your team has 50 hours of capacity and the following PBIs: 1. "Add dark mode to the app" (15 hours) 2. "Fix login timeout bug" (10 hours) 3. "Integrate Stripe payments" (25 hours) 4. "Update privacy policy page" (5 hours)

Constraints:
- The PO insists on delivering all 4 PBIs.
- The "Stripe payments" PBI depends on a backend API that won’t be ready until Day 5.

Your task:
- Plan the sprint (select PBIs, break into tasks, identify risks).
- Write a 1-sentence Sprint Goal.

Solution:
- Selected PBIs: 1, 2, 4 (total = 30 hours, leaving 20 hours buffer).
- Sprint Goal: "Improve user experience by adding dark mode and fixing critical login issues." - Risk Mitigation: Add a spike for Stripe integration (e.g., "Research Stripe API" – 5 hours) to prepare for next sprint.
- Why it works: Respects capacity, avoids dependencies, and delivers value.

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Official Scrum Guide: scrumguides.org (Read the "Sprint Planning" section).
2. Jira Sprint Planning Guide: Atlassian – Plan a Sprint.
3. Book: "Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland.
4. Template: Miro Sprint Planning Template.