Agile-and-Scrum: 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 teams (Scrum Guide 2020) who need to ship real work, not just talk about it.

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 how to build it (the Sprint Backlog). If you skip this or do it poorly, you’ll either: - Overcommit-Burnout, missed deadlines, and technical debt. - Undercommit-Wasted capacity, idle team members, and stakeholders losing trust. - Build the wrong thing-Features that don’t solve real problems, leading to rework.

Real-world scenario: You’re a Scrum Team working on a payment processing system. Your Product Owner (PO) says, "We need to support Apple Pay by next month." Your developers say, "The API docs are unclear, and we’ve never integrated with Apple’s system." Your QA says, "We need a sandbox environment to test this." Sprint Planning is where you align on: - What (Sprint Goal): "Enable Apple Pay for 90% of US users by Sprint end." - How (Sprint Backlog): "Research Apple’s API-Build a mock-Integrate-Test in sandbox-Deploy to staging."

If you skip this: - Developers might start coding without understanding Apple’s requirements-wasted effort. - QA might not have a test environment ready-blocked work. - The PO might assume the feature is "done" when it’s not-misaligned expectations.

Sprint Planning is your team’s "pre-flight checklist." Miss it, and your Sprint crashes.

2. Core Concepts & Components

3. Step-by-Step: How to Run Sprint Planning (Like a Pro)

Prerequisites

Product Backlog is refined (DEEP: Detailed, Estimated, Emergent, Prioritized). ? Team capacity is known (account for vacations, meetings, and unplanned work). ? Definition of Ready (DoR) is agreed upon (e.g., "PBIs must have acceptance criteria and dependencies identified"). ? Definition of Done (DoD) is clear (e.g., "Code reviewed, tested, deployed to staging").

Step 1: Set the Sprint Goal (5–10 min)

• PO proposes a goal (e.g., "Enable Apple Pay for US users").
• Team asks clarifying questions:
• "What’s the minimum viable version?" (e.g., "Just US, not Canada yet")
• "What’s the success metric?" (e.g., "90% of US users can pay with Apple Pay")
• Team commits to the goal (or negotiates a simpler one).
• Write it down (e.g., in Jira, Confluence, or a sticky note).

Trap: If the goal is too vague (e.g., "Improve payments"), the team will waste time arguing over scope.

Step 2: Review Capacity (5–10 min)

• Calculate available hours (e.g., 5 devs × 6 hours/day × 10 days = 300 hours).
• Subtract time for:
• Meetings (Daily Scrum, refinement, retro)-~10%
• Unplanned work (bugs, support)-~15%
• Total available capacity: ~225 hours
• Convert to story points (if using them):
• If team velocity is 50 points/Sprint, but capacity is 20% lower, adjust to 40 points.

Trap: If you ignore capacity, you’ll overcommit and miss the Sprint Goal.

Step 3: Select PBIs for the Sprint (15–30 min)

• PO presents top PBIs (prioritized by business value).
• Team pulls PBIs into the Sprint Backlog until capacity is full.
• For each PBI, ask:
• "Is this Ready?" (Meets DoR?)
• "Can we break it down into tasks?"
• "Are there dependencies or risks?"
• Example: | PBI | Estimate | Dependencies | Risks | |---------|-------------|------------------|-----------| | Integrate Apple Pay | 21 pts | Need Apple API keys | Apple’s docs are unclear | | Update checkout UI | 8 pts | None | None | | Fix payment timeout bug | 5 pts | None | None |

Trap: If you skip dependencies, you’ll block the team (e.g., "We can’t start until legal approves Apple’s terms").

Step 4: Break PBIs into Tasks (20–40 min)

• For each PBI, split into tasks (small enough to complete in 1–2 days).
• Example (Apple Pay PBI):
• [ ] Research Apple Pay API (2h)-Spike
• [ ] Request API keys from Apple (1h)-Dependency
• [ ] Set up sandbox environment (4h)
• [ ] Write API client (8h)
• [ ] Test with mock data (4h)
• [ ] Integrate with checkout flow (8h)
• [ ] Deploy to staging (2h)
• [ ] QA testing (4h)

Trap: If tasks are too big (e.g., "Implement Apple Pay"), you’ll lose visibility into progress.

Step 5: Assign Tasks & Identify Risks (10–15 min)

• Team volunteers for tasks (no forced assignments).
• Identify risks and mitigations: | Risk | Mitigation | |----------|---------------| | Apple’s API docs are unclear | Allocate a spike to research first | | Legal approval delays API keys | Escalate to PO to unblock early | | Sandbox environment not ready | Use a mock API for initial testing |

Trap: If you ignore risks, they’ll derail your Sprint.

Step 6: Commit to the Sprint Backlog (5 min)

• Team confirms:
• "We can deliver the Sprint Goal with this plan."
• "We’ve accounted for dependencies and risks."
• PO confirms:
• "This aligns with business priorities."
• Final Sprint Backlog is locked in (but can be adapted if new info emerges).

Trap: If the team doesn’t commit, they’ll lack ownership and miss the goal.

4.-Production-Ready Best Practices

Security & Compliance

• Never hardcode secrets (e.g., API keys) in tasks. Use vaults (AWS Secrets Manager, HashiCorp Vault).
• Identify compliance requirements early (e.g., "Apple Pay requires PCI-DSS compliance").

Cost Optimization

• Time-box spikes (e.g., "Spend max 2 days researching Apple’s API").
• Avoid "gold-plating" (e.g., "We don’t need Apple Pay for Canada yet").

Reliability & Maintainability

• Break tasks into 1–2 day chunks-Better visibility into progress.
• Tag tasks with dependencies (e.g., "Blocked by: Legal approval")-Easier to track blockers.

Observability

• Track progress daily (e.g., "How many tasks are ‘In Progress’ vs ‘Done’?").
• Update the Sprint Backlog in real-time (e.g., if a task takes longer, adjust estimates).

5. Common Mistakes & Traps

6.-Exam/Certification Focus (PSM, CSM, etc.)

Typical Question Patterns

1. "What’s the purpose of Sprint Planning?"
2. ? "To assign tasks to developers." (Too tactical)

3. "To define the Sprint Goal and create a plan to achieve it." (Strategic)

4. "Who decides what goes into the Sprint Backlog?"

5. ? "The Product Owner." (They prioritize, but the team pulls work.)

6. "The Developers, based on capacity and the Sprint Goal."

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

8. ? "They work overtime." (Scrum doesn’t encourage overtime.)
9. ? "They adapt the Sprint Backlog and focus on the Sprint Goal."

Key Trap Distinctions

• Sprint Goal vs. Sprint Backlog:
• Goal = What we want to achieve (e.g., "Enable Apple Pay").
• Backlog = How we’ll do it (tasks, dependencies, risks).
• Definition of Ready (DoR) vs. Definition of Done (DoD):
• DoR = Before a PBI enters the Sprint (e.g., "Acceptance criteria written").
• DoD = After work is completed (e.g., "Code reviewed, tested, deployed").

Common Scenario-Based Question

Question: "Your team is planning a Sprint, but the Product Owner keeps adding new PBIs mid-planning. What should you do?"

Answer: ? Stop and refine the Product Backlog first. Sprint Planning is not the time to discuss new work. The PO should prioritize and refine PBIs beforehand (e.g., in Backlog Refinement).

7.-Hands-On Challenge (With Solution)

Challenge:

Your team is planning a Sprint to "Improve the checkout flow" (Sprint Goal). The Product Backlog has:
1. "Reduce checkout steps from 5 to 3" (8 pts)
2. "Add guest checkout option" (5 pts)
3. "Fix ‘Payment Failed’ error" (3 pts)

Problem: - The team’s capacity is 15 points. - The "Reduce checkout steps" PBI is not refined (no acceptance criteria). - The "Payment Failed" bug is blocked by a dependency (needs a database fix from another team).

What do you do?

Solution:

1. Refine the "Reduce checkout steps" PBI first (e.g., "Acceptance criteria: Remove shipping address step, merge payment and confirmation steps").
2. Pull only the "Add guest checkout" and "Fix ‘Payment Failed’" PBIs (total: 8 pts).
3. Add a spike (e.g., "Research checkout flow improvements" – 3 pts).
4. Track the dependency (e.g., "Blocked: Waiting on DB team for ‘Payment Failed’ fix").

Why this works: - You stay within capacity (11/15 pts). - You avoid unrefined work (which would cause rework). - You mitigate the dependency risk (by tracking it early).

8.-Rapid-Reference Crib Sheet

9.-Where to Go Next

1. Scrum Guide 2020 – Sprint Planning (Official source)
2. Mountain Goat Software – Sprint Planning (Practical tips)
3. Scrum.org – Sprint Planning Tips (Real-world advice)
4. Atlassian – Sprint Planning Guide (Jira-focused)

Final Thought

Sprint Planning is not a meeting—it’s a battle plan. Treat it like a pre-flight checklist for your Sprint. If you skip it, you’ll crash. If you do it well, you’ll deliver real value, consistently.

Now go plan your next Sprint like a pro. ?