sprint-planning v1.0.0A

Immutable. This exact content is served forever at /api/v1/blob/cc824ddc12d66727.

---
name: sprint-planning
description: >
  Facilitates sprint planning with security debt baked in: capacity planning from rolling velocity,
  risk-weighted prioritization balancing feature value against security debt, commitment sizing, and
  a DevSecOps definition of done. For writing or refining the stories themselves, use
  user-story-writing instead. Triggers on: "plan the sprint", "sprint planning", "prioritize these
  stories", "how much can we commit", "balance security debt against features", "sprint capacity".
license: MIT
metadata:
  author: Community
  version: 1.0.0
  category: secure-sdlc
---

# Sprint Planning (Secure Value)

Help a Scrum team plan a sprint where security work competes fairly with features instead of being deferred forever. The Product Owner acts as a risk manager: features earn value, unresolved security debt accrues risk.

## Capacity Planning

1. **Velocity baseline**: use the rolling average of the last 3 completed sprints. If history is missing, plan conservatively and say the first sprints are calibration.
2. **Reserve ~20%** of capacity for security remediation and unplanned work. Teams that skip this reserve absorb security work by silently dropping committed stories.
3. **Carry-over rule**: if more than 30% of last sprint's commitment carried over, reduce this sprint's commitment — don't re-commit the same overload.
4. Account for real availability: holidays, on-call rotations, and any team member dedicating time to security champion duties.

## Risk-Weighted Prioritization

Score competing items with this framework, then sanity-check the result rather than following it blindly:

```
Security Debt Score = severity_points × exposure_multiplier
  severity_points: Critical 10 · High 5 · Medium 2 · Low 1
  exposure_multiplier: days_since_discovery / 30 (minimum 1)

Feature Value Score = business_impact (1-10) × user_reach (1-10) × revenue_or_risk_relevance (1-10)
```

**Hard rules that override scores:**
- Critical and High vulnerabilities enter the sprint now — they are not tradeable against features.
- Regulatory deadlines (compliance findings with dates) are non-negotiable; schedule them with buffer before the deadline.
- Security stories generated by threat modeling get capacity in the same sprint as the feature they protect, not "later".

## Planning Session Flow

1. Confirm sprint goal — one sentence, feature-oriented, achievable.
2. Apply the hard rules: pull in Critical/High security debt and deadline-driven items first.
3. Fill remaining capacity by score, keeping the 20% reserve untouched.
4. For each pulled story, verify it meets the team's definition of ready (clear acceptance criteria, estimable, dependencies known). Stories that fail go back for refinement — flag them rather than planning on hope.
5. Split any story estimated over ~1/3 of sprint capacity: split by workflow step, by happy-path-first, or by interface-then-implementation. Never split by architectural layer (a "frontend story" with no backend is not shippable).
6. Output the sprint plan: goal, committed items with estimates, capacity math, and explicit risks.

## DevSecOps Definition of Done

Recommend the team adopt (and adapt) this as their DoD; check candidate stories against it during planning:

- [ ] Code peer-reviewed
- [ ] Unit tests passing, coverage at or above the team's bar (e.g. 80%)
- [ ] SAST/dependency scans clean of new High/Critical findings
- [ ] Security acceptance criteria verified (where the story has them)
- [ ] Documentation/runbook updated where behavior changed
- [ ] Deployed to staging and verified

## Guidelines

- Make trade-offs visible: when a feature is deferred for security debt (or vice versa), record the decision and its rationale in the plan output so it's auditable later.
- Velocity is a planning tool, not a performance metric — never present it as a target to beat.
- If the user just wants prioritization without a full planning session, run only the Risk-Weighted Prioritization section and return the ranked list with reasoning.
- For writing the security stories themselves, defer to the security-story-writing skill; for identifying the threats, defer to the threat-modeling skill.