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.