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".
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".
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
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.
Reserve ~20% of capacity for security remediation and unplanned work. Teams that skip this reserve absorb security work by silently dropping committed stories.
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.
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:
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
Confirm sprint goal — one sentence, feature-oriented, achievable.
Apply the hard rules: pull in Critical/High security debt and deadline-driven items first.
Fill remaining capacity by score, keeping the 20% reserve untouched.
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.
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).
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.
