Size each fix by the effort it needs, not by its severity. Small means a version bump with no code change, medium means a bump with code or test changes, large means a major upgrade, replacement or redesign. Sizes let you add up the work and compare it with what your team clears in a period.
Why severity is the wrong size
A critical finding can be a one line bump. A low finding can need a framework migration. Severity tells you how soon to act. Effort tells you how much capacity it takes. A capacity plan needs both, kept in separate fields.
A three size scheme
| Size | What it looks like | Typical hands-on work |
|---|---|---|
| Small | Patch or minor bump, tests pass unchanged | Review and merge |
| Medium | Bump needs a code tweak, config change or new test | A focused session by one engineer |
| Large | Major upgrade, library replacement, no fixed version, or cross-service change | A planned piece of work, maybe several people |
Add a fourth label, Decision, for findings where the work is a choice: accept, mitigate or retire. Those take meeting time, not coding time.
How to assign a size
- Is a fixed version available? If not, it is Large or Decision.
- Is the change a patch or minor under your versioning scheme? If yes, start at Small.
- Does the changelog mention breaking changes or deprecations you use? If yes, Medium or Large.
- Do tests cover the code path? If not, move up one size, because verification costs more.
- Does the dependency sit in shared code? If yes, move up one size for coordination.
Keep the rules short enough that two engineers would size the same finding the same way. For semantic versioning risk, see how risky a patch, minor or major fix pull request is.
Calibrate with your own history
Do not borrow hours from anyone else. After a month, look at closed fixes by size and note the actual hands-on time from your tracker or from engineers' own estimates. Two things usually appear: Small really is small, and Large varies wildly. For Large work, estimate individually, as in estimating an upgrade from your own past upgrades.
Use sizes in the plan
Count the open backlog by size. Compare it with weekly throughput by size. You may find Small work clears easily and Large work never moves. That is a sign Large items need protected time, not more bots.
| Backlog pattern | Likely response |
|---|---|
| Mostly Small | Automate, batch, run an upgrade day |
| Many Medium | Improve tests, add reviewer time |
| Many Large | Schedule projects, consider replacement |
| Many Decision | Hold a triage session with an owner who can decide |
Pitfalls
- Sizing on the day of the report and never revisiting. Re-size when facts change.
- Letting size drive priority. Urgent work goes first whatever its size.
- Using sizes to measure people. They are a planning tool.
Where Safeguard fits
Safeguard dependency scanning surfaces fixed versions where they exist, which answers the first sizing question, and reachability analysis helps decide which findings need sizing at all.
Quick check
Should I estimate in hours?
Sizes are enough for planning at the backlog level. Use hours only for Large items, and base them on your own past work.
What size is a finding with no fix?
Treat it as Large or Decision, because the work is a mitigation, replacement or risk choice rather than a bump.
Last reviewed: 19 October 2026.
