Sprint Planning

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:

• Real-time task status updates (8 points)
• Activity feed display (5 points)
• Notification system MVP (8 points)
• WebSocket infrastructure (5 points)
• 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
• Dependencies and blockers to be aware of
• Team asks clarifying questions

**Part 2: Story Refinement and Estimation (2 hours)

"How complex is the work and what will done look like?"

• PM presents stories in priority order
• Engineering discusses technical approach
• Estimation using planning poker (30-40 stories/hour typical)
• Break down stories > 8 points
• Identify dependencies and risks

Part 3: Capacity Planning and Commitment (45 minutes)

"What can we realistically commit to?"

• Scrum master presents available capacity
• Team considers estimation results
• Decide which items to include in sprint
• Total committed points should be 75-85% of capacity
• Explicitly note what's NOT being done and why

Part 4: Sprint Planning and Kickoff (45 minutes)

"How will we execute and who does what?"

• Discuss technical approach for major items
• Identify who will take lead on each story
• Plan pair programming or knowledge sharing
• Clarify any remaining acceptance criteria
• Confirm sprint goal
• Set success criteria and metrics

Sprint Planning Checklist

• [ ] Product Manager has prioritized backlog
• [ ] Backlog items have acceptance criteria
• [ ] Stories >8 points are broken down
• [ ] Team has calculated available capacity
• [ ] Vacation, meetings, overhead accounted for
• [ ] Top 15-20 stories estimated
• [ ] Sprint goal clearly defined
• [ ] Team has committed to sprint (not mandatory)
• [ ] Success metrics agreed upon
• [ ] Dependencies identified and planned for
• [ ] Risks flagged and mitigation planned
• [ ] All team members understand goals and assignments

Daily Standup Management

Standup Format (15 minutes, time-boxed)

Three questions each person answers:

• "What did I accomplish yesterday?"
• "What will I accomplish today?"
• "What blockers do I have?"

Example:

• Developer A: "Finished user auth story (3 pts). Today: start password reset. No blockers."
• Developer B: "Code review and small bugfixes. Today: password reset tests. Waiting on database schema (blocker)."
• QA: "Tested auth flows. Today: edge case testing. Need password reset ready."

Standup discipline:

• Same time daily (consistency)
• 15 minute time box (keep focused)
• Stand up (energy/focus)
• Report on sprint commitments
• Capture blockers for follow-up

Blocker Resolution

Blocker formats:

• Dependency on another team
• Technical blockers (unclear requirements, architecture decision needed)
• Resource blockers (waiting for code review, infrastructure)
• External blockers (third-party service, customer response)

Blocker escalation:

• Flag in standup
• Scrum Master follows up immediately
• Resolve before next standup if possible
• Reassign work if blocker will last >1 day
• Don't let team get blocked

Sprint Metrics and Tracking

Key Sprint Metrics

Velocity (points completed per sprint)

• Definition: Points in stories marked "done" by end of sprint
• Calculation: Sum story points of completed items
• Tracked: Over last 4-6 sprints (trendline)
• Stable velocity: Good predictor for future sprints
• Rising velocity: Improving efficiency or easier work
• Falling velocity: Challenges, tech debt buildup

Burn-down Chart (work remaining over time)

Sprint Points Remaining
120 |
    | ● (Sprint start)
100 | \●
    |  \●
80  |   \●●
    |    \   ●
60  |     \●
    |      \
40  |       ●\
    |        \●
20  |         \●
    |          \●
0   |___________●●___→
    0  2  4  6  8  10  Days
      (ideal line shown)

• Slope = velocity
• Bumps = new work added mid-sprint (try to avoid)
• Flat spots = days with no progress (investigate)
• Trend should be downward toward zero by day 10

Scope Creep (points added/removed mid-sprint)

• Target: 0 (no mid-sprint changes)
• Acceptable: <5% of committed points
• Bad: >10% of committed points (scope not protected)

Defect Escape Rate (bugs found after sprint)

• Definition: % of stories that require follow-up fixes
• Target: <10%
• High rate: Quality issues (invest in testing)
• Low rate: Good QA process

Burndown Interpretation

Healthy sprint (burndown on track):

• Steady downward trend
• Minimal scope changes
• Completed by end of sprint
• Team confident in forecast

Scope creep sprint (creeping burndown):

• Work added throughout sprint
• Burndown appears stuck
• Team overcommitted or reactive
• Action: Stop adding work, review commitment process

Quality issue sprint (sudden jump back up):

• Spike in blockers or bugs found
• Unexpected rework discovered
• Requires investigation in retrospective
• Action: Reduce commitment, invest in QA

Blocked sprint (flat burndown):

• Team stuck on blockers
• Waiting for dependency resolution
• Work not progressing
• Action: Address blockers immediately, reassign work

Sprint Review and Retrospective

Sprint Review (30-45 minutes)

"What did we accomplish and what will customers see?"

Agenda:

• Context and sprint goal recap (2 min)
• Demo of completed work (20 min)
• Show working features
• Live demo on staging/production
• Gather feedback from stakeholders
• Incomplete work discussion (5 min)
• Why wasn't it finished?
• Will it carry to next sprint?
• Feedback and Q&A (10 min)
• Customer and stakeholder feedback
• Feature requests
• Directional feedback for future work

Demo best practices:

• Prepare demos in advance
• Show real data, not demo data
• Show edge cases and error handling
• Have a demo failure backup plan
• Explain "why" not just "what"

Sprint Retrospective (45-60 minutes)

"What went well? What can we improve?"

Three main questions:

• "What went well this sprint?"
• "What could we improve?"
• "What will we commit to trying next sprint?"

Retrospective format options:

Standard Format (45 min):

• Warm-up/icebreaker (5 min)
• Brainstorm went well (5 min)
• Brainstorm improvements (5 min)
• Vote on priority issues (5 min)
• Discuss top 2-3 issues (20 min)
• Define actions and commitments (5 min)

Sailboat Format (35 min):

Wind (what's moving us forward)
    ▲
    | ✓ Clear requirements
    | ✓ Good pairing
Anchor (what's slowing us)
    | ✗ Slow builds
    | ✗ Meetings interrupting focus
Rocks (what could sink us)
    | ⚠ Tech debt accumulation

Start-Stop-Continue Format (30 min):

• Start: New practices to adopt
• Stop: Practices to discontinue
• Continue: Good practices to maintain

Retrospective Actions and Commitment

Action items should be:

• Specific: "Implement automated tests for API endpoints" (not "improve testing")
• Measurable: "Reduce build time from 8 min to <3 min" (not "faster builds")
• Owner: Assigned to specific person or pair
• Timeline: Complete by mid-sprint checkpoint
• Tracked: Review in next retro

Example actions:

• "Set up code owner reviews by mid-sprint" (Owner: Tech lead)
• "Document API integration patterns" (Owner: Frontend lead)
• "Schedule focus time 9-11 AM daily" (Whole team commitment)
• "Limit Slack during standups" (Team commitment)

Retrospective metrics:

• Team identifies 3-5 improvement areas per sprint
• 60%+ of previous sprint actions completed
• Team morale trending up or stable
• Velocity stable or improving

Sprint Planning Checklist

• [ ] Backlog groomed and prioritized
• [ ] Top 20 items estimated
• [ ] Team capacity calculated
• [ ] Stories >8 points broken down
• [ ] Sprint goal defined and aligned
• [ ] Stories assigned to team members
• [ ] Dependencies and blockers identified
• [ ] Success metrics and acceptance criteria clear
• [ ] Story descriptions in JIRA/tracking system
• [ ] Team confident in commitment (feeling: 8/10)
• [ ] Sprint kickoff meeting completed
• [ ] Burndown chart setup and ready
• [ ] Daily standup time scheduled
• [ ] Sprint review and retro scheduled

Output Deliverables

• Sprint Plan - Goal, committed stories, capacity plan
• Story Estimates - Breakdown of all sprint items
• Capacity Analysis - Available capacity vs. commitment
• Burndown Dashboard - Track sprint progress daily
• Risk Register - Blockers and mitigation for sprint
• Team Commitments - Individual assignments and goals
• Success Metrics - How we'll measure sprint success
• Retro Actions - Documented improvements and commitments
• Velocity Trend - Historical data for forecasting