project-management
Sprint Planning Guide
Run effective sprint planning sessions — from backlog refinement through capacity allocation, commitment, and sprint goal definition with clear acceptance criteria.
sprint-planningagilebacklogcapacitycommitment
Works well with agents
Works well with skills
sprint-planning-guide/
SKILL.md
Markdown| 1 | |
| 2 | # Sprint Planning Guide |
| 3 | |
| 4 | ## Before you start |
| 5 | |
| 6 | Gather the following from the user: |
| 7 | |
| 8 | 1. **Sprint length** (1 week, 2 weeks, or custom) |
| 9 | 2. **Team size and composition** (How many engineers, designers, QA — and who is out this sprint) |
| 10 | 3. **Backlog state** (Is the backlog refined? Are the top items estimated and acceptance-criteria-ready?) |
| 11 | 4. **Carryover from last sprint** (Incomplete stories, bugs, or tech debt items that must continue) |
| 12 | 5. **External commitments** (Deadlines, cross-team dependencies, or stakeholder promises) |
| 13 | |
| 14 | If the user says "we just pull from the top of the backlog," push back: "Without a sprint goal, the team is doing task execution, not sprint planning. What outcome should be true at the end of this sprint that isn't true today?" |
| 15 | |
| 16 | ## Sprint planning template |
| 17 | |
| 18 | ### 1. Pre-Planning: Backlog Refinement |
| 19 | |
| 20 | Complete this **before** the planning meeting — not during it. |
| 21 | |
| 22 | **Refinement checklist (done 2-3 days before planning):** |
| 23 | |
| 24 | - [ ] Top 15-20 backlog items have clear descriptions and acceptance criteria |
| 25 | - [ ] Stories are estimated (story points, T-shirt sizes, or hours — pick one, stay consistent) |
| 26 | - [ ] Dependencies between stories are identified and documented |
| 27 | - [ ] Stories that require design, research, or external input are flagged |
| 28 | - [ ] Tech debt and bug items are groomed and prioritized alongside feature work |
| 29 | |
| 30 | If the backlog isn't refined, don't hold planning. Hold a refinement session instead. Planning with unrefined stories wastes everyone's time and produces unreliable commitments. |
| 31 | |
| 32 | ### 2. Capacity Calculation |
| 33 | |
| 34 | Calculate how much the team can realistically take on. |
| 35 | |
| 36 | ``` |
| 37 | Team capacity worksheet: |
| 38 | |
| 39 | | Team Member | Available Days | Focus Factor | Effective Days | |
| 40 | |-------------|---------------|-------------|----------------| |
| 41 | | Alice | 10 | 0.8 | 8.0 | |
| 42 | | Bob | 8 (PTO Fri) | 0.8 | 6.4 | |
| 43 | | Carol | 10 | 0.7 (on-call)| 7.0 | |
| 44 | | Dave | 5 (half sprint)| 0.8 | 4.0 | |
| 45 | | **Total** | **33** | | **25.4** | |
| 46 | ``` |
| 47 | |
| 48 | **Focus factor guidelines:** |
| 49 | - 0.8 = standard (accounts for meetings, code review, Slack) |
| 50 | - 0.7 = on-call rotation or heavy meeting week |
| 51 | - 0.6 = significant non-sprint responsibilities (hiring, cross-team support) |
| 52 | |
| 53 | Compare effective days to the team's historical velocity. If the team averages 30 story points per sprint at full capacity but has 80% capacity this sprint, plan for ~24 points. |
| 54 | |
| 55 | ### 3. Sprint Goal Definition |
| 56 | |
| 57 | Define 1-2 sprint goals before selecting stories. The goal answers: "What is the most important outcome of this sprint?" |
| 58 | |
| 59 | ``` |
| 60 | Sprint Goal: Users can complete checkout with saved payment methods. |
| 61 | |
| 62 | This is achieved when: |
| 63 | 1. Saved payment method selection is functional in checkout flow |
| 64 | 2. Payment processing works end-to-end with saved cards |
| 65 | 3. Error handling covers expired cards and declined transactions |
| 66 | ``` |
| 67 | |
| 68 | A good sprint goal is: |
| 69 | - **Outcome-oriented**: Describes what users can do, not what engineers will build |
| 70 | - **Achievable in one sprint**: Not a multi-sprint epic restated as a goal |
| 71 | - **Falsifiable**: At sprint review, you can definitively say "yes, we achieved this" or "no, we didn't" |
| 72 | |
| 73 | ### 4. Story Selection and Commitment |
| 74 | |
| 75 | With the goal defined and capacity known, select stories. |
| 76 | |
| 77 | **Selection process:** |
| 78 | |
| 79 | 1. Start with carryover items — these are already in progress and get priority |
| 80 | 2. Pull stories that directly support the sprint goal |
| 81 | 3. Add maintenance items (bugs, tech debt) — allocate 15-20% of capacity |
| 82 | 4. Check for dependencies — flag any story that's blocked by external teams |
| 83 | 5. Stop when you hit capacity. Do not overcommit. |
| 84 | |
| 85 | Record the final commitment as a table with columns: ID, Title, Points, Owner, Dependencies. Include the total points, capacity, and velocity average at the bottom for a sanity check. |
| 86 | |
| 87 | ### 5. Sprint Planning Meeting Agenda |
| 88 | |
| 89 | Run the meeting in 60 minutes or less for a 2-week sprint. |
| 90 | |
| 91 | Structure: 5 min reviewing last sprint results, 5 min announcing capacity/constraints, 10 min aligning on sprint goal, 25 min walking through stories and assigning owners, 10 min finalizing commitment, 5 min identifying risks. Key rules: no story refinement during planning (if it's not ready, it doesn't enter the sprint), every story must have an owner before the meeting ends. |
| 92 | |
| 93 | ### 6. Risk and Dependency Tracking |
| 94 | |
| 95 | At the end of planning, identify risks and assign mitigation owners. For each risk, document: what the risk is, its impact on the sprint goal, the mitigation plan, and who owns it. |
| 96 | |
| 97 | ## Quality checklist |
| 98 | |
| 99 | Before closing the planning session, verify: |
| 100 | |
| 101 | - [ ] A sprint goal is defined and the team can state it without reading notes |
| 102 | - [ ] Every story has an owner, an estimate, and acceptance criteria |
| 103 | - [ ] Total commitment is at or below team capacity (never above historical velocity) |
| 104 | - [ ] Carryover items from last sprint are accounted for |
| 105 | - [ ] At least 15% of capacity is reserved for bugs and tech debt |
| 106 | - [ ] Dependencies are identified with mitigation plans |
| 107 | - [ ] The planning meeting stayed under 60 minutes |
| 108 | |
| 109 | ## Common mistakes to avoid |
| 110 | |
| 111 | - **No sprint goal.** Without a goal, the team is executing a task list, not working toward an outcome. A sprint with 10 unrelated stories has no coherence and no way to make tradeoff decisions mid-sprint. |
| 112 | - **Planning without refined stories.** If the team spends 30 minutes debating what a story means during planning, it wasn't refined. Refinement and planning are separate ceremonies — never combine them. |
| 113 | - **Overcommitting.** Teams that commit to 110% of capacity every sprint build a culture of failure. Plan to 80-85% of historical velocity to leave room for the unexpected. |
| 114 | - **Ignoring carryover.** Incomplete stories from last sprint don't disappear. Account for them first — they consume capacity whether you acknowledge them or not. |
| 115 | - **Skipping the capacity calculation.** "We usually do about 30 points" ignores that two people are on PTO and one is on-call. Calculate capacity for this specific sprint. |
| 116 | - **All features, no maintenance.** Skipping tech debt and bug fixes for three sprints creates a fourth sprint where you can't ship features because the codebase is falling apart. Protect 15-20% for maintenance every sprint. |
| 117 |