pm-claude-skills/examples/samples/sprint-planning.md

---
skill: sprint-planning
title: Sprint Planning
input: "Team of 5, 2-week sprint, average velocity 30 points, one engineer out 3 days. Backlog: checkout redesign (8), payment retries (5), analytics events (3), bug bash (3), API rate limiting (5)."
source: generated by claude-sonnet-4-6
---

# Sprint 14 — 2-Week Planning Output

---

## Step 1: Capacity Calculation

Running the capacity model before touching the backlog.

```
Team:               5 engineers
Sprint days:        10 (2 weeks)
Focus hours/day:    6
One engineer out:   3 days → 3 lost focus-days

Total theoretical focus-days:  5 × 10 = 50
Adjusted focus-days:           50 − 3 = 47
Availability factor:           47 ÷ 50 = 0.94 → capped at 0.85 (meetings, admin, Slack)

Velocity-adjusted capacity:    30 × 0.85 = 25.5 → 26 points available
Recommended commitment (80%):  26 × 0.80 = ~21 points

No carry-overs reported → full 21 points available for new work.
```

> **Equivalent CLI call:**
> ```bash
> python3 scripts/capacity_calculator.py \
>   --team 5 --days 10 --velocity 30 \
>   --availability 0.85 --carryover 0
> # → Available: 26 pts | Recommended commit: 21 pts | Capacity for new work: 21 pts
> ```

---

## Step 2: Backlog Review & Story Assessment

| Story | Raw Est. | Flag | Decision |
|---|---|---|---|
| Checkout redesign | 8 | ⚠️ **Must split** — 8 pts, high uncertainty | Split below |
| Payment retries | 5 | ✅ Ready | Include |
| API rate limiting | 5 | ✅ Ready | Include |
| Analytics events | 3 | ✅ Ready | Include |
| Bug bash | 3 | ✅ Ready | Include |

**Checkout redesign (8) — mandatory split before committing:**

| Sub-story | Points | Rationale |
|---|---|---|
| Checkout redesign — layout & routing | 3 | New page structure, no logic changes |
| Checkout redesign — form validation & error states | 3 | Client-side logic, known patterns |
| Checkout redesign — integration with order service | 5 | API contract changes, needs design sign-off |

> The integration slice (5 pts) carries dependency risk — see Risks section. Pull it only if the API contract is confirmed before sprint start; otherwise defer to Sprint 15.

---

## Sprint 14 — 3 June to 14 June 2025

---

**Sprint Goal:**
> "This sprint we will deliver a reliable, polished checkout and payment experience so that users can complete purchases without hitting dead ends, measured by zero payment-retry silent failures in production and checkout task-completion rate ≥ 90% in usability smoke test."

---

**Team Capacity:** 21 story points committed (26 available, 80% rule applied; 5-person team at 85% availability)

---

### Sprint Backlog

| Priority | Story | Points | Owner | Acceptance Criteria |
|---|---|---|---|---|
| 1 | Checkout redesign — layout & routing | 3 | TBD | Given a logged-in user, when they initiate checkout, then they land on the redesigned page with correct route and no regression on existing order flow |
| 2 | Checkout redesign — form validation & error states | 3 | TBD | Given invalid input, when the user submits, then inline errors appear per field without page reload; given valid input, no false errors shown |
| 3 | Payment retries | 5 | TBD | Given a failed payment attempt, when the system retries, then it does so up to 3 times with exponential backoff; failed retries are logged with error code; user sees accurate status message |
| 4 | Analytics events | 3 | TBD | Given a user completes any checkout step, when the step fires, then the correct event name, user ID, and timestamp appear in the analytics pipeline within 30 seconds; no duplicate events |
| 5 | Bug bash | 3 | Whole team | Given the bug bash session (Day 8), when complete, then all P1 bugs discovered are filed with repro steps; at least 50% of P2s have owners assigned |
| — | API rate limiting | 5 | **Deferred to Sprint 15** | See rationale below |
| — | Checkout redesign — integration with order service | 5 | **Deferred to Sprint 15** | Blocked on API contract confirmation |

**Committed total: 17 points**
*(Intentionally under the 21-point ceiling — see rationale below)*

---

### Carry-Overs from Previous Sprint

None reported. ✅ Clean slate — full recommended capacity applied to new work.

---

### Capacity Rationale & Deferred Items

**Why only 17 of 21 points committed:**
The two deferred items (API rate limiting — 5 pts, checkout integration — 5 pts) together total 10 pts and both carry pre-conditions that aren't confirmed yet. Pulling them in speculatively would risk the sprint goal. The 4-point buffer below the 21-point ceiling absorbs:
- Unplanned bug fixes surfacing from the bug bash
- The absent engineer's knowledge areas (if they own context on payment systems)
- Any scope creep on the checkout layout work

If blockers resolve by **Day 2**, API rate limiting can be pulled in from the backlog to fill the buffer.

---

### Risks & Dependencies

| # | Risk | Severity | Mitigation |
|---|---|---|---|
| 1 | Checkout integration slice depends on confirmed API contract with order service | 🔴 High | Confirm contract with order service team **before Day 1**. If not confirmed by EOD Day 1, defer entire integration slice to Sprint 15. |
| 2 | Engineer absent 3 days — if they own payment systems context, retry logic is at risk | 🟡 Medium | Assign payment retries story to a different engineer now; schedule 30-min knowledge handoff before absence starts. |
| 3 | Bug bash (Day 8) may surface P1 issues requiring immediate sprint work | 🟡 Medium | Reserve the 4-pt buffer explicitly for bug bash fallout. Do not commit buffer to new stories before Day 8. |
| 4 | Analytics events story has no confirmed data-pipeline owner outside the team | 🟡 Medium | Identify pipeline contact on Day 1; confirm event schema is agreed before story is picked up. |
| 5 | Two 5-point stories deferred — if Sprint 15 also has high load, rate limiting may slip a second time | 🟢 Low | Flag both deferred items to Product as Sprint 15 P1 carry-ins now, not after this sprint closes. |

---

### Stories Flagged for Missing Acceptance Criteria

All five committed stories have acceptance criteria defined above. ✅

> If any AC above was written without Product Owner confirmation, **treat it as a draft** and validate during the planning meeting — do not carry a story into the sprint on assumed criteria.

---

## Sprint Planning Agenda — Day 1, 09:00–11:00

| Time | Block | Owner | Notes |
|---|---|---|---|
| 09:00–09:10 | Open: sprint goal read-aloud, capacity recap | Scrum Master | Confirm 17-pt commitment, name the 4-pt buffer explicitly |
| 09:10–09:25 | Risk walk-through | Scrum Master | Resolve Risk #1 (API contract) live if possible — go/no-go on checkout integration |
| 09:25–09:55 | Backlog walk — committed stories | Product Owner | Each story read aloud; team confirms AC or flags changes |
| 09:55–10:25 | Estimation confirmation & story splitting | Whole team | Validate checkout sub-stories; challenge any estimate that's changed since grooming |
| 10:25–10:50 | Ownership assignment | Whole team | Every story gets a named owner; absent engineer's stories reassigned |
| 10:50–10:58 | Buffer & deferred item decision | Product Owner + Tech Lead | Confirm API rate limiting pull-in criteria; set Day 2 deadline for decision |
| 10:58–11:00 | Commit & close | Scrum Master | Read sprint goal aloud one final time; team verbal confirmation |

---

## Quality Checklist

- [x] Sprint goal is outcome-focused and pass/fail scoreable at sprint end
- [x] Capacity uses 85% availability factor, not theoretical 100%
- [x] 80% commit rule applied (17 of 21 recommended points committed)
- [x] Every committed story has an acceptance criterion
- [x] 8-point story split before entering sprint
- [x] No carry-overs from previous sprint — accounted for in capacity
- [x] Absent engineer's impact modelled in availability factor and risk log
- [x] Deferred items flagged to Product as Sprint 15 pre-loads