Estimate security work the way you estimate any work with unknowns: size the parts you understand in points, put a timebox on the parts you do not, and write down what you assumed. A security ticket is rarely one task. It is usually a small known change wrapped around a large unknown.
Why security tickets blow up
Take a ticket that says "stop using the old hashing library." The code change might be ten lines. Finding every call site, handling data hashed with the old scheme, and coordinating a migration across services is where the days go. Teams estimate the ten lines and get surprised by everything else.
The surprise is not a security problem. It is a discovery problem. Most of the effort sits in finding out how far a weakness reaches.
Split every ticket into three parts
Before pointing a ticket, write three short lines.
- Find: how many places does this touch, and how will we know we found them all?
- Change: what is the edit once we know the places?
- Prove: how do we show it is fixed, by test, scan, or review?
Estimate Change in points as usual. Treat Find as a timebox, covered in the next section. Estimate Prove honestly, because a fix with no proof tends to come back as a repeat ticket.
Timebox the unknown
When Find is genuinely open, do not guess. Create a spike with a fixed limit, such as half a day, and a defined output: a list of call sites, a count, and a revised estimate for the real work. The spike ends when the time ends, even if the list is incomplete. A partial list with a stated gap is more useful than a promise of certainty.
Use reference tickets
Pick three tickets your team has already finished, one small, one medium, one large, and keep them as reference points. When a new security ticket arrives, ask which of the three it resembles. Comparing to your own past work beats comparing to an abstract scale, and it works for engineers who have never done security tasks before.
Add a note for coordination cost
Security fixes often need other teams: a library owner, a platform team, a customer who must rotate a key. Waiting time is not effort, but it still delays the sprint outcome. Record dependencies on the ticket and plan the start date around them, not the point value.
Watch for these traps
- Pointing the fix and ignoring the rollout.
- Giving a security ticket a low number because it feels urgent. Urgency is priority, not size.
- Letting a spike turn into the fix without a re-estimate.
- Counting a scanner's finding count as the size of the work. One root cause often explains many findings.
If your tooling reports which vulnerable functions your code actually calls, that cuts the Find step down. Safeguard's reachability analysis is one way to get that list for dependency findings, and you can try a free scan to see what it reports for your project.
Quick check
Should security tickets get fewer points because they are small code changes?
No. Size the whole effort including finding the affected places and proving the fix. A ten line change with a week of discovery is not a small ticket.
When should a security ticket become a spike first?
When you cannot say how many places are affected or how you would verify the fix. Timebox the spike and have it produce a revised estimate.
Last reviewed: 19 October 2026.
