There is no universal percentage. Set a standing slice of each sprint for upgrades, start from what your team already spends on them, and revisit it every quarter using three numbers: hours spent, upgrades completed, and how far behind your dependencies are. A visible, steady slice beats occasional heroic upgrade weeks.
Why a fixed number is the wrong starting point
You will see rules of thumb quoted online, such as "reserve a fifth of every sprint". Treat these as opinions, not findings. A team with a three-year-old lockfile and thin tests needs a very different budget from a team that merges small bumps every week.
What you can defend in a planning meeting is your own history. Pull the last two quarters of pull requests that touched manifests or lockfiles and add up the engineer time. That figure, even if rough, is your real baseline. Most managers find it is not zero, it is just invisible, scattered across interrupts and late-night fixes.
Three inputs that set the slice
- Current drift. How far behind are you? Count direct dependencies with a newer major version, and note any runtime or base image nearing end of support.
- Change safety. How quickly can you tell that an upgrade broke something? Fast tests and a staged rollout make upgrades cheap. Slow or missing tests make each one expensive.
- Exposure. Internet-facing services and anything handling customer data justify a larger, steadier slice than an internal tool.
| Situation | Starting approach |
|---|---|
| Frequent small bumps, good tests | A small standing slice, mostly absorbed by routine merges |
| Several majors behind, decent tests | A larger slice for one quarter, then step down |
| Thin tests, many majors behind | Fund test coverage first, then upgrades |
| End-of-life runtime within two quarters | Ring-fence named capacity with an owner and a date |
How to turn it into a planning artifact
Put upgrades on the board as normal work, not as a side effort. Create one epic per quarter, with child tickets sized using your own past upgrades (see how to estimate an upgrade from your own history). Give the epic an owner.
Keep the slice separate from unplanned security work. If an urgent advisory eats the whole slice in week three, you want that to be visible as a trade-off, not a quiet slip. Our post on reserving a buffer for unplanned security upgrades covers that split.
How to adjust each quarter
At quarter end, compare three things:
- Planned upgrade hours against actual hours.
- Upgrades completed against upgrades planned.
- Drift at the start and end, using a simple measure such as the number of direct dependencies a major version behind.
If drift is falling and actuals match the plan, hold the slice. If drift is flat while you spend steadily, the backlog is being fed as fast as you drain it, so look at how many new dependencies you add. If actuals overshoot the plan twice in a row, your estimates are too optimistic, so fix the estimates before asking for more time.
What to say when someone asks why
Keep it short. "We spend roughly this much a quarter already, unplanned. A planned slice makes it predictable and lets us say no to emergencies that are not emergencies." That framing treats the slice as risk control, not a request for a favour.
Where Safeguard fits
Safeguard's SBOM and dependency scanning gives you an inventory to size drift from, and reachability analysis helps you rank which upgrades matter first. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is 20 percent a good default?
It is a common guess, but nothing in it is specific to your codebase. Use your own two quarters of history as the baseline and adjust from there.
Should security upgrades come out of the same slice?
Keep a separate, smaller buffer for unplanned security work so that routine upgrades do not silently stop whenever an advisory lands.
Last reviewed: 19 October 2026.
