HKSM
12.2 Retrospect Release
| 12.2 Retrospect Release | ||
|---|---|---|
| Inputs | Tools | Outputs |
Bold ITTOs are mandatory.
Retrospect Release is a structured, end-of-release workshop where the Scrum team and key stakeholders inspect outcomes, analyze root causes, and agree on measurable improvements for future releases and organizational practices.
Purpose & When to Use
Run this event after a release has been delivered and accepted, before planning the next release. The purpose is to step back from individual Sprints and review the release as a whole—customer value delivered, quality, predictability, flow, and handoffs—so the team can lock in what worked and fix systemic issues that only show up across multiple Sprints.
Use it whenever a set of increments is packaged and deployed as a release, including major or minor releases, and when cross-team or cross-department collaboration influenced outcomes.
Mini Flow (How It’s Done)
- Prepare: Gather data from Sprint Reviews/Retrospectives, release goals, acceptance records, metrics (lead time, escaped defects, reliability, cost, satisfaction), and significant events.
- Invite the right people: Scrum Team, Product Owner, Scrum Master, representatives from QA, DevOps/Operations, Support, Security, and key business stakeholders.
- Set the stage: Clarify goals, working agreements, and timebox; agree on a success statement for the session.
- Review the release timeline: Visualize major decisions, scope changes, incidents, and milestones; surface facts before opinions.
- Inspect outcomes: Compare planned vs actual scope, value, quality, time, and budget; review customer feedback and production metrics.
- Analyze root causes: Use techniques like 5 Whys, fishbone, or affinity mapping to find systemic causes, not individual blame.
- Identify improvements at three levels: team practices (e.g., Definition of Done), product/technical (e.g., test automation gaps), and organizational/system (e.g., release approvals, environments).
- Prioritize and decide: Dot-vote or WSJF to select a small set of high-impact changes; make each action SMART with an owner and due date.
- Plan follow-through: Add top actions to the next Sprint Backlog or an improvement backlog; update working agreements, Definition of Done/Ready, and process documentation.
- Share and close: Publish a short summary with decisions, actions, and acknowledgments; celebrate wins to reinforce good practices.
Quality & Acceptance Checklist
- Customer acceptance of the release is recorded, and release goals are evaluated (met, partially met, missed) with evidence.
- Complete, reliable data set reviewed: metrics, feedback, defects, outages, cycle/lead time, deployment stats, and helpdesk signals.
- At least 3–5 high-impact improvements identified across team, technical, and organizational levels.
- Actions are SMART, have named owners, target dates, and a clear measurement of success.
- Top actions are integrated into the next Sprint/Release plan; not left as a separate wish list.
- Definition of Done/Ready and working agreements updated if needed.
- Lessons captured in the organizational knowledge base and communicated to stakeholders.
- Risks, constraints, and dependencies that affected the release are documented with mitigation strategies.
- Celebrations and recognition noted to reinforce positive behaviors.
Common Mistakes & Exam Traps
- Venting session with no data: skipping facts and metrics leads to opinions and weak actions.
- Narrow attendance: excluding Ops/Support/Security causes recurring deployment and production issues.
- Only Sprint-level thinking: release-level bottlenecks (environments, approvals, integration) remain invisible.
- No follow-through: actions lack owners or are not added to the next Sprint Backlog.
- Blame and performance review: retaliatory discussions shut down learning; the Scrum Master should protect psychological safety.
- Confusing events: Retrospect Release is not Sprint Retrospective (end of sprint) and not a Product Backlog refinement session.
- Replanning scope: the goal is process and system improvement, not changing release content after the fact.
- Skipping when the release "went fine": you still capture what to keep and small optimizations.
- Overloading with too many actions: pick a few high-leverage changes and make them stick.
PMP/SCRUM Example Question
After a four‑Sprint release has been deployed and accepted, the Product Owner wants to move straight into planning the next release to save time. What should the Scrum Master advocate as the next best step?
- Begin backlog refinement to pull more features into the next Sprint.
- Conduct a Retrospect Release to inspect outcomes and agree on a few high‑impact improvements.
- Hold a Sprint Review to gather stakeholder feedback on the deployed features.
- Schedule daily standups with Operations to monitor production stability for two weeks.
Correct Answer: B. The end of a release calls for a release‑level retrospective to analyze cross‑sprint results, capture lessons, and define measurable improvement actions for the next release; Sprint Review already occurred per sprint, and daily standups/Backlog refinement do not replace the need to learn at the release level.
