mohitagw15856
7.8 KiB
skill, title, input, source
| skill | title | input | source |
|---|---|---|---|
| sprint-planning | Sprint Planning | 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). | 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:
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
- Sprint goal is outcome-focused and pass/fail scoreable at sprint end
- Capacity uses 85% availability factor, not theoretical 100%
- 80% commit rule applied (17 of 21 recommended points committed)
- Every committed story has an acceptance criterion
- 8-point story split before entering sprint
- No carry-overs from previous sprint — accounted for in capacity
- Absent engineer's impact modelled in availability factor and risk log
- Deferred items flagged to Product as Sprint 15 pre-loads