Budget for unplanned security work by reserving a buffer sized from your own history, writing down in advance what the buffer displaces when it overflows, and reviewing actuals every sprint. Do not plan to 100 percent of capacity. Surprise advisories are a normal cost of shipping software.
Define what counts as unplanned
Unplanned security work is anything that enters mid-sprint and cannot wait for the next planning session. Typical sources are a new advisory in a library you ship, a customer reporting a weakness, or a request from an auditor with a date attached.
Do not count work that was merely forgotten at planning. That belongs in the planned bucket next time. Keeping the definition tight keeps the data useful.
Measure before you guess
For the last six sprints, list every ticket that arrived after sprint start and was security related. Record the hours or points each took. Then compute the range, not just the average. If one sprint took 2 points and another took 13, the buffer has to cover the bad one often enough to matter.
If you have no history, start with a small buffer and treat the first quarter as data collection. The Scrum Guide notes that no changes should be made during a sprint that would endanger the Sprint Goal, and that scope may be renegotiated with the Product Owner as more is learned. A buffer is the pre-agreed way to do that without a fight each time.
Decide the overflow rule
A buffer is not infinite. Before the sprint starts, agree what happens when the buffer is gone:
| Situation | Default action |
|---|---|
| Buffer has room | Pull the item in, no discussion |
| Buffer is full, item is urgent | Swap with a named lower value item |
| Buffer is full, item can wait | Add to the top of the next sprint |
The named swap matters. Choose the first thing that will be dropped, such as a stretch story, so the product owner is not surprised.
Keep the buffer honest
Two habits help:
- Release unused buffer late. If nothing happens by mid-sprint, pull in pre-approved backlog items, not new commitments.
- Log every use. A short note of what consumed the buffer feeds next quarter's sizing and shows leaders what security interrupts really cost.
If the buffer is empty every sprint, it is probably too small, or your intake process lets low urgency items skip the queue. Check one intake queue for security work to see how to triage before the work reaches the sprint.
Reduce the surprise rate
Buffers handle noise, and prevention shrinks it. Pin and update dependencies on a schedule so advisories arrive in a steady trickle, not a pile. Use risk signals to separate vulnerabilities that matter from those that do not. EPSS, for example, publishes a daily probability that a CVE will be exploited in the next 30 days, and the CISA catalog lists those known to be exploited, which helps decide what really interrupts a sprint.
Safeguard's reachability analysis can show whether a vulnerable function is called in your code, which turns many urgent looking advisories into scheduled work instead of interrupts. Its policies and gates can also catch new problems at pull request time, before they become mid-sprint surprises.
Review it every retrospective
Add one question to the retro: did the buffer hold? If yes twice in a row, you may be able to shrink it. If no twice in a row, grow it or fix the source. A related set of prompts is in security questions for every sprint retrospective.
Quick check
How big should the buffer be?
Derive it from your last several sprints of unplanned security tickets, and size it to cover a bad sprint most of the time. If you have no data, start small and measure.
Who decides what gets bumped?
The product owner and the engineering manager, in advance. Writing the swap rule before the sprint prevents an argument at the worst moment.
Sources
Last reviewed: 19 October 2026.
