Sprint Planning

Overview

The Sprint Planning skill enables product managers and engineering leaders to organize work into effective sprints that balance delivery with quality. It covers goal-setting, capacity planning, story estimation, and retrospective analysis for continuous improvement.

When to Use This Skill

• Planning 2-week or 1-week sprints
• Estimating feature complexity and effort
• Balancing feature work with technical debt
• Setting realistic sprint commitments
• Conducting effective sprint kickoffs
• Running productive retrospectives
• Improving team velocity and processes

Sprint Planning Framework

Pre-Planning Preparation (1 week before)

Step 1: Backlog Grooming

• Review top 20 backlog items
• Ensure items have clear acceptance criteria
• Clarify any ambiguous requirements with PM
• Break down large items into 2-4 point stories
• Mark dependencies and blockers
• Update priority ordering

Step 2: Capacity Planning

• Count available person-days (total days - planned PTO)
• Account for meetings and overhead (20% typical)
• Calculate net capacity for dev work
• Identify team members with special focus areas

Step 3: Dependency Review

• Identify items blocked by previous sprints
• Ensure unblocking work is prioritized
• Flag external dependencies (design, third-party)
• Plan workarounds for external delays

Story Point Estimation

Estimation Framework (Fibonacci Scale)

Story points represent relative complexity/effort, not hours

1 point    - Trivial changes: typo fixes, simple config updates
           Example: "Fix button color from blue to red"

2 points   - Simple changes: straightforward feature, 1-2 day effort
           Example: "Add email field to user profile form"

3 points   - Small feature: touches 1-2 components, clear requirements
           Example: "Implement forgot password email flow"

5 points   - Medium feature: crosses multiple systems, some complexity
           Example: "Add two-factor authentication"

8 points   - Complex feature: significant complexity, multiple dependencies
           Example: "Build real-time notification system"

13 points  - Very complex: major feature, high uncertainty
           Example: "Rebuild authentication system"

21 points  - Epic (break down): too large for single sprint
           Example: "Complete mobile app redesign"

Estimation Process (Planning Poker)

Step 1: Story presentation (2 minutes)

• PM reads story aloud
• Clarifies acceptance criteria
• Discusses edge cases and dependencies

Step 2: Silent estimation (1-2 minutes)

• Team members estimate independently
• Use Fibonacci cards or online tool
• No discussion yet

Step 3: Discussion (3-5 minutes)

• High estimates speak first ("Why did you estimate 8?")
• Low estimates speak next ("Why did you estimate 3?")
• PM clarifies requirements if confusion
• Team discusses complexity/uncertainty

Step 4: Re-estimate (1 minute)

• Final round of estimation
• Usually converges to one or two adjacent numbers
• If still divergent (1 and 8), break story down further

Step 5: Acceptance (by story owner)

• Estimate accepted if team agreement
• Document final estimate
• Flag if story needs re-breaking

Estimation Tips

Avoid over-estimating:

• Assign 1-2 point stories to experienced team member working on same system
• Break down unknowns into separate story
• Don't penalize for learning time

Avoid under-estimating:

• Account for testing and bug fixes (usually 20-30%)
• Include integration work and code review
• Consider system complexity, not just happy path
• Don't be optimistic about "easy" items

Stories that are often underestimated:

• Anything involving databases or data migration
• Cross-browser or multi-platform support
• Anything with integration requirements
• Anything involving third-party APIs
• Bug fixes (more complex than features)

Estimation anchoring:

• Compare to similar stories completed in past
• Use team velocity trend (average points completed per sprint)
• If estimate > 8 points, break into smaller pieces
• Reserve estimation time: typical team estimates 20-30 stories in 2 hours

Sprint Goal Definition

Goal-Setting Framework

Effective sprint goal characteristics:

• Clear and specific (not vague)
• Achievable in single sprint (not epic)
• Represents customer/business value (not just tasks)
• Motivating for team (connects to larger mission)
• Measurable (clear definition of done)

Sprint Goal Template:

Sprint 12 Goal: "Enable real-time project collaboration"

Supporting stories:

1. Real-time task status updates (8 points)
2. Activity feed display (5 points)
3. Notification system MVP (8 points)
4. WebSocket infrastructure (5 points)
5. Technical debt: Upgrade database drivers (3 points)

Non-goals (explicitly out of scope):

• Email notification integration (planned for Sprint 13)
• Mobile notification support (Sprint 13)
• Slack integration (Sprint 14)

Success criteria:

• Team delivers 80%+ of committed points
• Feature is production-ready with <2% error rate
• Performance <200ms latency for real-time updates

Why this matters:

• Reduces meeting-heavy workflows for teams
• Foundation for async communication improvements
• Expected to improve retention by 8%

Multi-Team Goal Alignment

Team Goals → Sprint Goal → Initiative Goal → Quarterly Goal

Quarterly Goal: Improve team communication efficiency ├─ Initiative 1: Real-time collaboration (Sprints 12-13) │ ├─ Team A Goal: Build WebSocket infrastructure │ ├─ Team B Goal: Create activity feeds │ └─ Team C Goal: Implement notifications ├─ Initiative 2: Mobile app (Sprints 14-15) └─ Initiative 3: Advanced analytics (Sprints 16)

Sprint Capacity Planning

Team Capacity Calculation

Total sprint capacity (2 weeks):

• Team size: 8 engineers
• Days per engineer: 10 days (2 weeks)
• Total person-days: 80 person-days

Subtract unavailable time:

• Vacation: 2 people × 2 days = 4 person-days
• Conferences/training: 1 person × 2 days = 2 person-days
• Holidays: 0 person-days
• Available person-days: 80 - 6 = 74 person-days

Subtract overhead and meetings:

• Daily standup: 15 min × 10 days × 8 people = 2 person-days
• Sprint planning: 4 hours = 0.5 person-days
• Sprint review/retro: 3 hours = 0.375 person-days
• 1-on-1s and admin: 1 hour/week × 8 people = 1.6 person-days
• Meetings/overhead total: ~4.5 person-days

Net development capacity: 74 - 4.5 = 69.5 person-days

Points available (based on velocity):

• Historical velocity: 120 points per sprint (over last 4 sprints)
• Adjusted for current capacity: 120 × (69.5/74) = 112 points target

Balanced Work Distribution

Recommended allocation:

• Feature stories: 85 points (76%)
• Bug fixes: 15 points (13%)
• Technical debt: 12 points (11%)
• Total committed: 112 points

By team/focus area:

• Backend: 40 points (35%)
• Frontend: 35 points (31%)
• Mobile: 20 points (18%)
• QA/Infrastructure: 17 points (15%)

Buffer and Contingency

Conservative estimation (90% confidence):

• Committed points: 85 (75% capacity)
• Buffer: 27 points (25% capacity)
• Buffer used for: Bugs, unplanned work, opportunities

Medium estimation (75% confidence):

• Committed points: 112 (100% capacity)
• Requires: Perfect execution, no major blockers

Aggressive estimation (50% confidence):

• Committed points: 130+ (>100% capacity)
• Results in: Incomplete sprints, team burnout (avoid)

Recommendation: Commit 85-95 points per sprint (75-85% capacity)

Sprint Planning Meeting Structure

Sprint Planning Meeting Agenda (4 hours for 2-week sprint)

Part 1: Context and Goal Setting (30 minutes)

"What will we accomplish this sprint and why?"

• Product Manager presents top priority items
• Context on customer feedback driving priorities
• Business goals for the sprint
• Dependenc