Measure how many security fixes each team actually ships per sprint, using several past sprints for a stable average, then compare it with the inflow of new findings. If inflow exceeds throughput, the backlog grows, and the gap is the capacity case you take to leadership.
Why throughput beats wishes
Executives often ask for a date when the backlog will be gone. Without a throughput figure, any date is a guess. With it, the arithmetic is simple: backlog divided by net weekly reduction. That gives a range, not a promise, but it is honest.
How to measure it
- Choose a period of at least four to six sprints so one unusual sprint does not dominate.
- Count verified fixes per sprint, not pull requests opened. Group findings by the change that fixed them, since one change can close many.
- Record the effort type: routine version bump, code change, or major upgrade.
- Note the share of sprint time spent on security work, if tracked.
- Compute the median per sprint for each effort type.
Counting findings and counting fixes are different. A single base image update can close dozens of findings. Report both, so a team is not judged on a number that depends on grouping.
Compare with inflow
| Number | Meaning |
|---|---|
| Inflow per sprint | New findings arriving |
| Throughput per sprint | Findings closed by verified fixes |
| Net | Backlog change per sprint |
If net is positive for several sprints, you have three levers: reduce inflow, raise throughput, or accept a larger backlog with explicit risk decisions. Name which one you are asking for.
Raise throughput without more people
- Group routine updates into scheduled batches.
- Automate low risk version bumps, with review and tests.
- Fix shared components once, such as base images and internal libraries.
- Remove unused dependencies, which removes findings without a fix.
- Keep owners clear so findings are not passed around.
Automated fix proposals can help, but they need review like any change. Track how many are accepted and how many are reverted so you know whether they save time.
Pitfalls
- Treating all findings as equal effort. A major framework upgrade is not a version bump.
- Ignoring planned work. If the sprint is fully booked with features, there is no capacity to measure.
- Using the number to rank engineers. It describes a team's system, not an individual.
Present the case
One slide: inflow, throughput, net, and a proposal, for example "reserve a fixed share of each sprint for security upgrades for two quarters, then reassess." Ask for a decision, not sympathy.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
See which findings can be closed by a single upgrade, which is what drives throughput.
Quick check
Should capacity be measured per person?
No. Measure per team and per sprint. Person level numbers invite gaming and misread shared work.
What if we have no sprint history?
Start tracking now and use a short window with a note on low confidence. Rough data you share honestly beats none.
Last reviewed: 19 October 2026.
