Looking back on a whole release: the release retrospective

After four Sprints, a team ships its first release. The next Monday it begins planning the next Sprint, and everything the whole effort taught it, about the vendors, the approvals, the early estimates and the stakeholder who changed the goal twice, goes home with the people who noticed it. A release retrospective is how that knowledge is kept.

What the sources say

The Scrum Guide has one retrospective, at the end of each Sprint, to plan ways to increase quality and effectiveness. It has no event for looking back across several Sprints, and does not forbid one. A team that wants a wider look is free to hold it, and the Guide's wording about inspecting processes, tools and the Definition of Done already supports the idea.

The SBOK® Guide adds a process for it. Its Retrospect Release process completes a release: stakeholders and core team members come together to reflect on the release and identify, document and internalise the lessons learned. Often these lead to agreed actionable improvements for future releases. Its Retrospect Release Meeting is used to find ways to improve team collaboration and effectiveness in future releases, and covers positives, negatives and opportunities. It is not time-boxed, may be held in person or virtually, and includes the core team and the business stakeholders. If a suggested improvement is outside the authority of the team, it is escalated to the appropriate executives.

Its outputs are agreed actionable improvements, action items with owners and due dates, non-functional items to add to the backlog, and updates to the guidance the organisation keeps.

How it differs from the Sprint Retrospective

The wider group matters. Many of the biggest problems in a release, such as slow approvals, late decisions and unclear sponsorship, sit outside the team. The Sprint Retrospective cannot fix them because the people who can are not in the room.

What to ask

A release is a long enough stretch to ask questions a Sprint cannot answer.

• Did we deliver the value we said we would? Compare the outcome with the vision and the release plan. See release planning.
• How accurate was our plan? Plot the forecast against what happened and ask why it moved.
• Which decisions helped, and which hurt? Ordering, scope boundaries, Sprint length, team makeup.
• What did the stakeholders experience? Were reviews useful? Did they know what was coming?
• What did the release process teach us? Deployment, communication, support readiness.
• What would we keep, stop or start next time? The SBOK's three headings, which map well here.
• What requirements surfaced late? The SBOK notes that non-functional needs, such as response time, capacity and security, often appear only at the reviews and retrospectives, and should be added to the backlog when found.
• What needs to leave the team? Some problems need an executive. Name them and who will carry them up.

Pick a few. Nobody can think well about thirty questions.

How to run it

The SBOK's retrospective tools carry over: an opening exercise to set the tone, a visual format such as engines and anchors, and metrics from the release. A suggested structure, which is ours:

1. Frame it (10 minutes). State the purpose and what will happen to the output.
2. Review the data (20 minutes). Show the plan against the result: dates, scope, quality, cost, stakeholder feedback.
3. Collect observations (30 minutes). Positives, negatives and opportunities, from everybody.
4. Find causes (30 minutes). Group, vote and ask why for the top items.
5. Agree actions (20 minutes). A few, each with an owner and a date. Separate those the team can do from those that need someone else.
6. Close (10 minutes). Say who will report back, and when.

Run it soon after the release, while memories are fresh, and do not combine it with the celebration. Both deserve their own time.

When there is no single release

Many teams today release continuously, so there is no moment that marks "the release". The idea still applies, with a different trigger. Pick a regular interval, such as every quarter or every few months, or a natural milestone such as a major feature or a change in the Product Goal, and hold the wide look then. The questions are the same: did the value arrive, how did the plan fare, and what does the organisation need to change? What matters is that someone outside the daily rhythm of Sprints gets a chance to see the pattern across several of them, because patterns are invisible one Sprint at a time, and a regular wide look is how a team notices that the same cause keeps costing it time.

Making it matter

The danger is a report nobody reads. Three habits help.

• Convert findings into backlog items or agreements. An action on the next Sprint Backlog is read. A page in a folder is not.
• Escalate with an ask. "Approvals took eleven days against a plan of three. We propose a standing approver" is something an executive can say yes to.
• Keep the lessons where the next team will look. The SBOK treats the guidance body's job as making sure lessons from all projects are embedded in the organisation, not lost. For a small team that might mean a short page in the project template.

These ideas also sit with how to make retrospective actions happen: few, specific, owned and checked.

Common mistakes

• Skipping it because the team is already on the next thing. That is exactly when learning gets lost.
• Too many people with no structure. A large group needs facilitation.
• Blame. A release review that turns into finding fault stops being honest.
• Only the team's view. Without stakeholders, the biggest causes go unnamed.
• No follow-through. If last release's actions are not reviewed, people stop contributing.
• Treating the release as the end of learning. The product lives on, and so does the team.

How to practise it

In the simulator, the last step looks back on the whole project: the value delivered, the return on investment and the technical lessons, before the project is closed and the scorecard is produced.