Ask seven questions: what we planned versus finished, where estimates were wrong, what surprised us, what we deferred and why, which process steps slowed us down, what we should automate, and what next quarter should look like. Bring data, keep it to 45 minutes, and leave with three decisions.
Before the meeting
Pull four simple numbers so the discussion starts from facts:
- Upgrade tickets planned, started and closed.
- Estimated hours against actual hours for the biggest five.
- Number of upgrade pull requests that were reverted or rolled back.
- Drift at quarter start and quarter end, using whichever measure you chose, such as direct dependencies a major version behind.
Share them a day ahead so the meeting is not spent reading a spreadsheet.
The seven questions
1. What did we plan, and what did we finish? Compare the committed list to the done list. Do not defend the gap yet. Just state it.
2. Where were our estimates wrong, and in which direction? If big upgrades overran every time, adjust the size buckets. Our note on estimating from your own past upgrades shows how to keep the history that makes this possible.
3. What surprised us? A removed API, a plugin that lagged, a test suite that hid a problem. Surprises are the raw material for the next spike.
4. What did we defer, and is the reason still true? Review the deferred list. Items without a reason should either get one or move back into the plan.
5. Which steps slowed us down? Slow review, slow CI, a manual deploy, unclear ownership. Choose the single biggest drag.
6. What should be automated or templated? Repeated work is a candidate for a script, a bot rule, a codemod, or a runbook. See what a codemod is and when to use one.
7. What does next quarter look like? Draft the shortlist while the lessons are fresh.
Outputs to leave with
| Output | Owner |
|---|---|
| Adjusted size buckets or capacity slice | Manager |
| One process fix to try next quarter | Named engineer |
| Updated deferred list with reasons | Team lead |
Three decisions beat fifteen notes. If the retro produces a long list, rank it and keep the top three.
Keep it blameless
Upgrades fail for ordinary reasons: tests that did not cover a path, notes that were thin, a release that changed behaviour without saying so. Frame findings as properties of the system, not mistakes of a person.
A word on the customer-facing side
If an upgrade caused an incident or a delay a customer noticed, give it its own short write-up instead of burying it in the retro. That keeps the retro practical and gives the incident its due attention.
Where Safeguard fits
Safeguard's dependency scanning and compliance evidence automation can supply the before and after data this retro needs, such as what was upgraded and when. A free scan is at gold.safeguard.sh/scan.
Quick check
How long should the retro be?
Forty-five minutes is enough if the numbers are shared in advance. Longer meetings tend to drift into individual tickets.
Who should attend?
The engineers who did the upgrades, the manager, and a security or platform partner if one is involved.
Last reviewed: 19 October 2026.
