Fit security work into sprints by putting it on the same board as everything else, sizing it like normal tickets, reserving a visible slice of capacity for it, and ordering it by risk rather than by who shouted. Security work that lives in a separate list gets deferred forever.
Why it gets dropped
Feature work has a product owner, a deadline and a customer. Security work usually has none of those, so it loses every tie. The fix is not a reminder email. It is giving security items the same structure as any other item: a ticket, an owner, an estimate and a place in the order.
Four habits
1. One board. Security tickets sit in the team backlog, labelled, not in a separate tool the team never opens.
2. Reserved capacity. Agree a fixed slice of each sprint for security and maintenance work, set by the team and manager together. Treat it like the on-call allowance: planned, not heroic. Pick a figure that fits your team and revisit it; there is no standard that fits everyone.
3. Risk based ordering. Order security tickets by exploitation evidence, reachability and exposure, and put the top item in the sprint even when features press.
4. Definition of done. Add a short security check to the definition of done for relevant stories so new work does not add debt.
A sprint routine
| Moment | Security action |
|---|---|
| Before planning | Champion prepares the short list of top findings |
| Planning | Pull in the top one to three items, size them, assign owners |
| Mid sprint | Check that security items are moving, same as other work |
| Review | Show fixed items alongside features |
| Retrospective | Ask whether security work blocked or helped delivery |
Sizing security tickets
A dependency upgrade can be one point or eight, depending on breaking changes. Size it after a quick look, not by gut feeling. Where a proposed fix already exists, such as an automated upgrade pull request, the work is review and testing rather than investigation, and the estimate falls.
Talking to product owners
Frame the trade in terms they care about: a customer questionnaire that will be blocked, a contractual deadline, a flaw that is under active exploitation. Avoid vague "best practice" arguments. If the item is truly low risk, say so and let it wait. Credibility from honest prioritisation buys you the big asks later.
What to avoid
- Hiding security work inside feature tickets, which makes it invisible
- A quarterly "security sprint" that stops everything else
- Giving the security team's backlog to developers without context
- Setting capacity by fear, then abandoning it at the first deadline
Quick check
What share of a sprint should security take?
It depends on your backlog and risk. Start with a small agreed slice, track whether the top findings actually get closed, and adjust.
Should security tickets be exempt from estimation?
No. Estimates make the work plannable and let product owners see trade offs.
Safeguard's autonomous remediation with fix pull requests is off by default and every category starts on Manual, so a team can review proposed fixes within normal sprint work. Try a free scan to build a first ordered list.
Last reviewed: 19 October 2026.
