name: sprint-planning description: "Plan sprints with story point estimation, capacity planning, sprint goals, and retrospective frameworks. Organize teams for effective iteration with clear goals, realistic commitments, and continuous improvement."
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