# Sprint Planning > 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. - Skill: `w95/sprint-planning` (Agent Skill) - Install (CLI): `npx skillmds add w95/sprint-planning` - Raw SKILL.md: https://api.skillmd.com/api/skills/w95/sprint-planning/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: w95 (https://skillmd.com/u/w95) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/w95/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:** 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 - 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:** 1. "What did I accomplish yesterday?" 2. "What will I accomplish today?" 3. "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:** 1. Context and sprint goal recap (2 min) 2. Demo of completed work (20 min) - Show working features - Live demo on staging/production - Gather feedback from stakeholders 3. Incomplete work discussion (5 min) - Why wasn't it finished? - Will it carry to next sprint? 4. 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:** 1. "What went well this sprint?" 2. "What could we improve?" 3. "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 1. **Sprint Plan** - Goal, committed stories, capacity plan 2. **Story Estimates** - Breakdown of all sprint items 3. **Capacity Analysis** - Available capacity vs. commitment 4. **Burndown Dashboard** - Track sprint progress daily 5. **Risk Register** - Blockers and mitigation for sprint 6. **Team Commitments** - Individual assignments and goals 7. **Success Metrics** - How we'll measure sprint success 8. **Retro Actions** - Documented improvements and commitments 9. **Velocity Trend** - Historical data for forecasting