HKSM

A time-boxed end-of-sprint meeting where the Scrum Team inspects how they worked and agrees on concrete improvements for the next sprint. It uses structured facilitation and root-cause techniques to surface better ways of working. The outcome is a short list of actionable changes and possible updates to Done Criteria and team working agreements.

Key Points

• Tool and technique used in the Retrospect Sprint process to improve team performance.
• Time-boxed and held after Demonstrate and Validate Sprint, before the next Sprint Planning.
• Focuses on process, collaboration, quality, and tools rather than individual blame.
• Produces Agreed Actionable Improvements with owners and target dates.
• May update Done Criteria, team working agreements, and the Impediment Log.
• Facilitated by the Scrum Master; attended by the Scrum Team and Product Owner.

Purpose of Analysis

The meeting analyzes how the sprint was executed to uncover what helped, what hindered, and where waste occurred. The team inspects trends in flow, quality, and communication to identify a few high-impact changes. The intent is continuous improvement through empirical learning and immediate adaptation in the next sprint.

Method Steps

1. Set the stage: confirm time-box, purpose, working agreement, and psychological safety; review agenda.
2. Review previous actions: check if past improvements were implemented and whether they worked.
3. Gather data: look at burndown, velocity, defects, impediments, escaped work, and feedback from the sprint review.
4. Generate insights: use techniques like 5 Whys, fishbone diagrams, speedboat, or ESVP to find root causes.
5. Decide improvements: brainstorm, cluster, and dot-vote to select 1–3 changes with highest value and feasibility.
6. Make them actionable: define clear actions, owners, success criteria, and when to start (ideally next sprint).
7. Close: appreciate contributions, confirm documentation, and communicate how actions will be tracked.

Inputs Needed

• Sprint Burndown or Burnup, velocity trend, and cycle/lead time data.
• Impediment Log and decisions or delays encountered during the sprint.
• Defect metrics, escaped defects, test coverage, and quality findings.
• Feedback and observations from Demonstrate and Validate Sprint.
• Team working agreement and current Done Criteria.
• Agreed Actionable Improvements from the previous Retrospect Sprint.
• Scrumboard snapshots or flow metrics (e.g., WIP, blocked items).

Outputs Produced

• Agreed Actionable Improvements with owners, due dates, and success measures.
• Updated Done Criteria and updated team working agreements, if needed.
• Updates to the Impediment Log and identified risks for follow-up.
• Improvement items added to the Prioritized Product Backlog or next Sprint Backlog as appropriate.
• Captured lessons learned for organizational knowledge and future sprints.

Interpretation Tips

• Limit commitments to a small number of changes the team can implement immediately.
• Tie actions to measurable signals (e.g., reduce average blockers, increase code review completion rate).
• Target root causes rather than symptoms; prefer prevention over detection where possible.
• Ensure ownership is clear and progress is visible on the Scrumboard or improvement tracker.
• Carry over unfinished improvements deliberately, not by default; revalidate their value each sprint.

Example

A team observes multiple late-stage defects and inconsistent code reviews. During the meeting they use 5 Whys and find unclear Done Criteria and overloading of one reviewer as root causes. They agree to update Done Criteria to require peer review and unit test thresholds, introduce a WIP limit for reviews, and rotate review duty. Each action has an owner and will be tracked in the next sprint.

Pitfalls

• Turning the meeting into a complaint session without root-cause analysis.
• Creating too many actions, leading to weak follow-through.
• Lack of safety and facilitation, causing silence or blame.
• Skipping data and relying only on opinions, which biases decisions.
• Not integrating actions into the next sprint, so improvements never materialize.
• Rehashing product scope instead of focusing on process and collaboration.

PMP/SCRUM Example Question

At the end of a sprint, the team identifies several process issues. To ensure improvement, what is the most appropriate outcome of the Retrospect Sprint Meeting?

1. A finalized release plan approved by stakeholders.
2. An updated Sprint Forecast with more user stories added.
3. An agreed list of actionable improvements with owners, possibly updating Done Criteria.
4. A change request to extend the current sprint by one week.

Correct Answer: C — An agreed list of actionable improvements with owners, possibly updating Done Criteria.

Explanation: The Retrospect Sprint Meeting produces Agreed Actionable Improvements and may update working agreements and Done Criteria. It does not change the current sprint scope, extend the sprint, or finalize release plans.