Give three numbers for each task: best case, most likely, and worst case. Combine them as the best case plus four times the likely case plus the worst case, divided by six. Report the result with a spread. This gives managers a range they can plan against instead of a single hopeful date.
Why one number fails
Security tasks have fat tails. A dependency upgrade usually takes a day, but the one time it pulls in a breaking change it takes a week. A single point estimate hides that. People anchor on the likely case, and the schedule has no room for the bad one.
Three-point estimation is a technique for building an approximate distribution of outcomes from limited information. It is only as good as the three inputs, so the method forces a conversation about what could go wrong.
The formula
Using the PERT style weighting:
- E, the expected value, is (a + 4m + b) divided by 6.
- SD, the standard deviation, is (b minus a) divided by 6.
Here a is the best case, m is the most likely, and b is the worst case. The source notes that accuracy can be no better than the three starting points, and that assuming a distribution shape with little basis has clear dangers. Treat the output as a planning aid.
Worked example
These hours are made up to show the arithmetic.
| Task | Best (a) | Likely (m) | Worst (b) | E | SD |
|---|---|---|---|---|---|
| Upgrade vulnerable library | 2 | 4 | 16 | 5.7 | 2.3 |
| Add input validation to one endpoint | 3 | 6 | 12 | 6.5 | 1.5 |
| Write regression test and review | 2 | 3 | 6 | 3.3 | 0.7 |
For example, the first row is (2 + 16 + 16) divided by 6, which is about 5.7 hours, and (16 minus 2) divided by 6, about 2.3.
Totals: E adds up to 15.5 hours. For the combined SD, square each SD, add them, and take the square root: about 2.8. The source gives roughly E plus or minus SD as a 68 percent range, so about 12.7 to 18.3 hours, under the assumption that the estimates are uncorrelated. Round to "two to two and a half days" when you speak.
How to pick honest inputs
- Best case means everything goes right, not a fantasy. Ask for a case that would surprise you if beaten.
- Worst case means a realistic bad outcome, not a catastrophe. Ask what happens if the first fix does not work.
- Likely is the single most probable outcome, not the average of the other two.
Estimate as a pair or group when you can. People who do not know the code will give wider ranges, and that is information.
Where the technique breaks
Tasks that share a cause are not independent. If three fixes all depend on one framework upgrade, their delays arrive together and the SD calculation understates the risk. Group them under one estimate. Also, three-point numbers do not include waiting for review or deploys, so add queue time separately, as in how to estimate security work in story points.
What to tell stakeholders
Say: "Likely two to two and a half days of work, plus review time, with a tail risk if the upgrade breaks callers." Then record what actually happened. After a quarter, compare actual to the range and adjust your habit. If the actuals sit above the worst case often, your worst case is too gentle.
Safeguard's CLI includes a fix dry run that previews dependency changes, which helps narrow the best and worst case before anyone starts. See preview dependency fixes with the Safeguard CLI.
Quick check
Is three-point estimation the same as padding?
No. Padding hides a buffer inside one number. Three points show the range openly, so the tail risk can be discussed and planned.
Should I use it for every ticket?
No. Use it for tasks with real uncertainty, like upgrades and migrations. Small routine fixes can use reference tickets.
Sources
Last reviewed: 19 October 2026.
