Estimate a dependency upgrade by looking at what similar upgrades actually cost your team before. Sort past upgrades into classes such as patch, minor and major, record elapsed time for each, and quote the range for the matching class. This beats guessing from the changelog.
The method has a name
Reference class forecasting predicts the outcome of a planned action by looking at the actual outcomes of similar past actions. It grew out of work by Daniel Kahneman and Amos Tversky, who found that people tend to underestimate the costs and completion times of planned actions because they take an inside view, focusing on the details of the task in front of them.
An upgrade is a perfect fit. You think "just bump the version," while your own history shows the last three major bumps each took a week.
How to build the estimate
Step 1: collect the history
Pull the last 10 to 20 dependency upgrade pull requests from your repositories. For each, record:
- The kind of change: patch, minor or major version, or a switch to a different package
- Elapsed time from first commit to deploy, and separately the hands-on time if you know it
- Whether tests broke, and whether other code had to change
- Whether the package is a direct or transitive dependency
If your history is thin, borrow from adjacent teams who use the same stack.
Step 2: build a small table
Here is an example layout with made up numbers, only to show the shape.
| Class | Count | Typical elapsed time | Worst seen |
|---|---|---|---|
| Patch, direct | 12 | Same day | 2 days |
| Minor, direct | 8 | 1 to 2 days | 1 week |
| Major, direct | 4 | 1 to 2 weeks | 5 weeks |
| Transitive, forced via override | 5 | 1 day | 3 days |
Do not trust the semver label blindly. Semantic versioning is a promise from the maintainer, not a guarantee. See semver patch, minor and major: how risky is this fix PR for what to check.
Step 3: adjust for the case in front of you
The class gives a starting range. Adjust with a short list of questions:
- How many places in the code call the package's changed APIs?
- How good is test coverage around those places?
- Does the release note list breaking changes?
- Is the deploy pipeline slow or gated by a weekly window?
Each yes to a risky question pushes you toward the worst seen number, not the typical one. Say so out loud. "Typical for this class is two days, but we have thin tests here, so plan for the worst seen."
Keep the table alive
After each upgrade, add a row. After a quarter you will have a better table than any estimator's gut. Review it at a planning session, and use it to size security fixes alongside features. For tasks with wide ranges, combine this with a three-point estimate as in three-point estimates for security fixes.
Try it yourself
In the demo, look at how a fix is presented once it is available, and note which details, such as the version jump, you would feed into your own reference table.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning shows whether a vulnerable package is direct or transitive and which version fixes it, which are the inputs for picking the right row in your table. Its fix pull requests are off by default and every category starts on Manual.
Quick check
What if we have no history to use?
Start recording now, and for the first quarter use a wide range and a spike for anything uncertain. Borrowing data from a neighbouring team on the same stack is better than none.
Does elapsed time or effort matter more?
For scheduling, elapsed time, because it includes waiting for review and deploys. Track hands-on effort too if you plan capacity in hours.
Sources
Last reviewed: 19 October 2026.
