// week 01 · day 04 · thu

Allocate Capacity and Set Goals.

$/sprint-plan · ~20 min
// 01 · what it does

Plan before the sprint starts.

sprint-plan has two modes. Analyze mode assesses backlog health — flagging stories that need splitting, stale tickets, missing data stories, dependency conflicts, and oversized items that have been miscategorized as single stories. Draft mode builds a sprint plan: it does the capacity math, selects stories against priorities and constraints, sequences them by dependency, and writes sprint goals as outcomes rather than task lists.

Sprint planning fails in predictable ways — too much scope relative to capacity, carryover items that crowd out new work, goals that describe activity instead of outcomes, and backlog items that never get the scrutiny they'd need to be sprint-ready. sprint-plan catches these before the sprint starts. The Analyze mode is especially useful before a planning meeting: it surfaces the backlog problems a team would otherwise spend 40 minutes discovering in the room.

Day 4 is the planning skill in Week 1 because by now you've produced artifacts (Day 1), reviewed them (Day 2), and broken them into stories (Day 3). Sprint planning is where you decide what actually gets built next — it's the moment when all the prior work either becomes committed scope or gets deferred. After this week you'll have run the full writing-to-planning cycle.

// 02 · sample prompts

Two ways in.

prompt.basic.txt 
/sprint-plan

Draft a sprint plan for my team:

Team: 4 engineers, 2-week sprint, ~16 story points capacity.
Goal: finish the user onboarding redesign and start work on search filters.
Backlog: onboarding-01 (8 pts), onboarding-02 (5 pts), search-01 (5 pts), search-02 (3 pts), search-03 (3 pts), tech-debt-01 (2 pts).
Carryover from last sprint: onboarding-01, 60% done.
prompt.advanced.txt 
/sprint-plan

Run Analyze mode on this backlog first, then Draft mode for the sprint plan.

Sprint context:
- Sprint length: 2 weeks (Wed–Tue)
- Team capacity: 6 engineers, but Omar L. is on PTO days 3–6 and Elena T. is on on-call rotation at 50% capacity. Effective capacity: approximately 18 points.
- Priority goal: reduce risk for Android GA and instrument Instant Book adoption before rollout expansion.
- Planning capacity rule: never commit above 85% of available points.

Carryover from last sprint:
- AND-142: Payment failure retry state — 80% complete, blocked on QA reproduction (owner: Nina W.). Required for Android GA.
- IB-087: Guide opt-in analytics events — not started, was deprioritized last sprint, required for rollout decision (owner: Nina W.; Fernando Lopez to validate definitions). No estimate yet.

Candidate backlog:
- AND-151: Fix push notification reliability for booking reminders (5 pts) — Android, blocks Android GA
- AND-152: Add payment edge-case regression tests (3 pts) — QA, unblocks AND-142 if QA can repro
- IB-088: Add calendar conflict warning before guide opts into Instant Book (5 pts) — backend + iOS, depends on IB-087 being instrumented first [DEPENDENCY CONFLICT — IB-087 not started but IB-088 is scheduled this sprint]
- IB-089: Add opt-in funnel dashboard events (3 pts) — backend, no Figma needed, this is IB-087's replacement ticket with a cleaner scope
- IB-090: Guide-facing Instant Book education modal (2 pts) — iOS + Android [ANDROID WORK — serialized]
- OPS-044: Support macro update for cancellation policy questions (1 pt) — no engineering, PM + support
- DATA-027: Cancellation reason taxonomy cleanup (3 pts) — backend data, last touched 4 sprints ago [STALE — verify if still relevant]
- DISC-019: Guide listing setup — pricing guidance UI (8 pts) — iOS + backend, no Figma attached yet [NOT READY — missing Figma, missing AC]
- DISC-020: Guide listing setup — example listing preview (13 pts) — iOS + backend + Android [OVERSIZED — likely a multi-sprint epic, needs splitting]
- DISC-021: Guide listing setup — milestone email trigger events (2 pts) — backend data story for DISC-019 [dependency: DISC-019 must ship first]
- DISC-022: Guide listing setup — onboarding checklist UI (5 pts) — iOS only
- AND-153: Datadog alert configuration for Android push reliability (2 pts) — infra, no product AC needed
- RETRO-011: Add retro action item tracking to sprint retrospective template (1 pt) — process, no engineering
- IB-091: Flexible Instant Book advance-notice window — backend schema design (3 pts) — exploratory, no acceptance criteria [NO AC — this is a discovery spike, not a story]
- ARCH-007: Migrate booking service to updated payment SDK (5 pts) — tech debt, 3 sprints old, blocks future payment work [STALE-BUT-LOAD-BEARING — needs prioritization call]
- PM-REQUEST-004: Add "save for later" wishlist feature — requested by Priya Anand (Marketing) mid-sprint, no estimate, no AC, no Figma [NOT READY — new request, not groomed]
// 03 · reflection

Three questions.

  1. 01What did the backlog health analysis surface that you would have discovered — or not discovered — in a planning meeting?
  2. 02How did the sprint goals the skill wrote differ from how you would have framed them — and which framing would be more useful to an engineer reading it on Day 1 of the sprint?
  3. 03Which backlog item did the skill defer that you would have tried to fit in — and was its reasoning right?
← Day 3 Day 5 →