Run a hardening sprint for a one-off, well-defined cleanup such as a framework migration or an audit deadline. Use steady allocation for recurring work like dependency updates. Most teams need both, with the steady slice as the default and a sprint reserved for exceptions.
What each approach is
A hardening sprint sets aside a whole sprint, or a large part of one, for security and reliability work. Features pause. Steady allocation reserves a fixed share of every sprint, so security work competes with nothing and ships all the time.
The Scrum Guide says that during a sprint no changes should be made that endanger the Sprint Goal. A hardening sprint simply makes the Sprint Goal a security one, which keeps it consistent with the framework rather than an exception to it.
A decision table
| Situation | Better fit |
|---|---|
| Large migration with a clear end | Hardening sprint |
| Backlog of old findings with a deadline | Hardening sprint, then steady slice |
| Weekly dependency updates | Steady allocation |
| New advisories arriving daily | Steady allocation with a buffer |
| Post-incident remediation across many services | Short hardening sprint, then roadmap work |
| Team is already behind on features | Steady allocation, smaller slice |
Why the sprint format wins sometimes
Big security work has a setup cost. People need context, environments and reviewers. Bundling it lets everyone pay that cost once. It also gives a clear story for executives: one block, one result.
It works best when the scope is written before it starts. "Clean up security" fails. "Remove the legacy session library from all four services" succeeds.
Why it often fails
Three patterns repeat:
- No exit criteria. The sprint ends with half the scope done and no agreement on what finishes it.
- A cliff afterwards. Security work stops entirely, the backlog regrows, and in a quarter the team asks for another sprint.
- Everyone is too busy. Features slip, and pressure builds to cancel the next one.
The cliff is the biggest. A hardening sprint should come with a steady slice behind it, so the gains hold.
How to run one well
- Pick a theme with a measurable outcome, such as a count of findings of a given type reaching zero in named services.
- Size the scope from your own history. If you lack it, use a time-boxed spike first, as covered in how to time-box a security spike story.
- Name an owner per workstream and one person who can say no to additions.
- Hold features that depend on the same code, so you avoid merge fights.
- End with a short review: what shipped, what did not, what steady work keeps the gain.
How to pitch it to product
Lead with the cost of continuing as is. Show the age and count of open items, the cost of delay on the top few, and a plan that ends. Product owners accept a bounded, dated request more easily than an open ended one. For the pricing side of this conversation, see how to explain security debt to executives.
Safeguard can help scope the sprint: SBOM and dependency scanning list what you ship, and reachability analysis shows which findings sit in code that runs, so the sprint targets real exposure first. You can try the free scan at gold.safeguard.sh/scan.
Quick check
How long should a hardening sprint be?
As long as the written scope needs, up to one sprint. If it needs more, split the scope into themed pieces and schedule them across quarters.
Can a hardening sprint replace steady allocation?
No. Without steady work behind it, the backlog regrows. Use the sprint to clear a pile, and the steady slice to keep it clear.
Sources
Last reviewed: 19 October 2026.
