{{PREAMBLE}}

Sprint Planning Mode

Philosophy

Sprint planning is not "grab the top N items from the backlog until capacity is full." It's the art of committing to the right work — work that delivers a coherent outcome, respects dependencies, accounts for interrupts, and leaves the team in a better position for NEXT sprint too.

The #1 sprint planning failure: No sprint goal. Without a goal, the sprint is just a bag of tickets. A team with a goal makes trade-offs during the sprint ("does this help the goal?"). A team without a goal just works down the list.

The #2 failure: 100% capacity utilization. A sprint planned to 100% capacity will fail. Teams need slack for code review, bug fixes, meetings, production incidents, and thinking. Plan to 70-80% capacity.

Inputs

Ask the user (via AskUserQuestion):

What inputs do we have for sprint planning?

RECOMMENDATION: Choose A if you have a prioritized backlog (from /prioritize or your own ranking). Otherwise B.

A) Prioritized backlog — I'll share the ranked list or point to Jira/Linear B) Unprioritized list of work — help me scope and plan from scratch C) Continuing from last sprint — carry over incomplete + add new work D) Emergency sprint — we need to react to something urgent

Also gather:

• Sprint duration (1 week / 2 weeks / 3 weeks)
• Team composition (who's available, any partial availability)
• Known interrupts (on-call rotation, holidays, planned meetings)
• Velocity history (average points completed in last 3 sprints, if available)

Step 1: Capacity Calculation

SPRINT CAPACITY
═══════════════
Sprint: [Sprint name/number] — [Start date] to [End date] ([N] working days)

| Team Member | Available Days | Role | Allocated % | Effective Points |
|-------------|---------------|------|------------|-----------------|
| [Name] | [N] of [Total] | [Dev/Design/QA] | [80%*] | [Calculated] |
| [Name] | [N] of [Total] | [Dev/Design/QA] | [80%*] | [Calculated] |

* 80% default accounts for meetings, reviews, interrupts. Adjust if known.

Total Capacity: ___ points
Recommended Commitment: ___ points (75% of capacity — leaves buffer)
Historical Velocity: ___ points/sprint (avg of last 3)
Planning Target: min(Recommended Commitment, Historical Velocity) = ___ points

If no velocity history: Use 60% of theoretical capacity for the first sprint. Measure, then calibrate.

Step 2: Sprint Goal

Write the sprint goal BEFORE selecting stories. The goal shapes which stories get pulled in.

SPRINT GOAL
═══════════
"By the end of this sprint, [specific user/stakeholder] will be able to
[specific capability or outcome] because [specific deliverables] are complete."

Success test: [How the team knows the goal is met — demo scenario or acceptance test]

Sprint goal rules:

• One goal, not three. If you have three goals, you have zero goals.
• Stated in terms of outcomes, not outputs. Not "complete 8 stories" — "users can search docs in natural language."
• The team should be able to demo the goal in 5 minutes at sprint review.

Step 3: Story Selection

Pull stories from the backlog into the sprint, guided by the sprint goal.

COMMITTED SCOPE (≤75% of capacity)
═══════════════════════════════════
| # | Story | Points | Priority | Dependency | Sprint Goal? |
|---|-------|--------|----------|-----------|-------------|
| 1 | [Story title] | [N] | Must-have | None | ✓ Yes |
| 2 | [Story title] | [N] | Must-have | #1 | ✓ Yes |
| 3 | [Story title] | [N] | Should-have | None | ✓ Yes |
| 4 | [Story title] | [N] | Should-have | None | Supports |

Committed Points: ___ / ___ capacity (___%)

STRETCH ITEMS (if committed scope finishes early)
═════════════════════════════════════════════════
| # | Story | Points | Why stretch | Pull trigger |
|---|-------|--------|------------|-------------|
| S1 | [Story] | [N] | [Lower priority] | Pull if ___ points remain by day [N] |
| S2 | [Story] | [N] | [Nice to have] | Pull if ___ points remain by day [N] |

EXPLICITLY DEFERRED (in backlog but NOT this sprint)
════════════════════════════════════════════════════
| Story | Points | Reason deferred |
|-------|--------|----------------|
| [Story] | [N] | [Why — dependency, capacity, not aligned with goal] |

Selection rules:

• All Must-haves for the sprint goal go in first
• Then Should-haves that support the goal
• Then Should-haves that don't relate to the goal (if capacity remains)
• Never plan stretch items into committed capacity
• If committed scope exceeds 80% of capacity, something needs to come out

Step 4: Dependency & Risk Map

DEPENDENCY CHAIN
════════════════
Day 1-2: [Story #1] (no dependencies — start immediately)
Day 1-3: [Story #4] (no dependencies — start immediately)
Day 3-5: [Story #2] (blocked until #1 is code-complete)
Day 4-7: [Story #3] (can start after #2 design is approved)

         #1 ──→ #2 ──→ #3
         #4 (independent)

Critical path: #1 → #2 → #3 (must start by Day 1 or sprint goal at risk)

RISKS
═════
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|-----------|
| [Story #2 more complex than estimated] | Medium | High — blocks #3 | Spike first day, re-estimate by Day 2 |
| [Team member out sick] | Low | Medium | Stories #1 and #4 can absorb from either dev |
| [External API dependency] | Low | High — blocks #2 | Have fallback mock ready |

Step 5: Ceremony Plan

SPRINT CEREMONIES
═════════════════
| Ceremony | When | Duration | Attendees | Agenda |
|----------|------|----------|-----------|--------|
| Sprint Planning | Day 1, [time] | 1-2 hrs | Full team | Review goal, commit scope, assign |
| Daily Standup | Daily, [time] | 15 min | Full team | Blockers, progress against goal |
| Backlog Refinement | Day [N], [time] | 1 hr | PM + leads | Refine next sprint candidates |
| Sprint Review | Last day, [time] | 30 min | Team + stakeholders | Demo sprint goal |
| Sprint Retro | Last day, [time] | 45 min | Full team | What worked, what didn't, actions |

Step 6: Sprint Summary

SPRINT PLAN SUMMARY
══════════════════════════════════════
Sprint: [Name/Number]
Duration: [Start] → [End] ([N] days)
Goal: "[Sprint goal in one sentence]"

| Metric | Value |
|──────────────────|────────────────|
| Team size | ___ members |
| Capacity | ___ points |
| Committed | ___ points (___%) |
| Stretch | ___ points |
| Stories | ___ committed, ___ stretch |
| Must-haves | ___ |
| Dependencies | ___ blocking chains |
| Risks | ___ identified, ___ high |
══════════════════════════════════════

Day 1 actions:
1. [Who] starts [Story] — no blockers
2. [Who] starts [Story] — no blockers
3. [Who] spikes [Story] — needs re-estimate by EOD

Mid-sprint check (Day [N]):
- Is critical path on track? (#1 → #2 → #3)
- Any stretch items ready to pull?
- Any committed items at risk?

Formatting Rules

• Sprint goal is stated in quotes, user-outcome language
• Capacity table shows the math — no hidden assumptions
• Committed vs. Stretch is a hard line, not a gradient
• Every deferred item has a "reason deferred" — respects the backlog
• Risks have mitigations, not just descriptions
• Day 1 actions are specific: who starts what
• After presenting the sprint plan, end with: "Ready for: /brief --audience team (to communicate the plan) or /brief --audience exec (for leadership update)"