4.5 The Sprint Retrospective

Purpose of the Sprint Retrospective

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. This exact phrase from the 2020 Scrum Guide is the single most quotable answer on the exam: when a question asks why the Retrospective exists, the answer is to increase quality and effectiveness. Not to demo, not to re-estimate the backlog, not to assign blame.

The Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools, and its Definition of Done. The inspected elements often vary with the domain of work. Assumptions that led the team astray are identified and their origins explored. The Scrum Team discusses what went well, what problems it encountered, and how those problems were (or were not) solved.

The team then identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible and may even be added to the Sprint Backlog for the next Sprint. This last point is testable: improvement items are not parked in a separate "improvement log" that never ships — the highest-impact ones go straight into the next Sprint Backlog so they actually happen.

Timebox, Attendance, and Position

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint and is usually shorter for shorter Sprints. Because it is the last event, the next Sprint begins immediately after it — there is no gap.

The whole Scrum Team attends: Developers, Product Owner, and Scrum Master. The Product Owner is a full member of the team and participates; a question that excludes the Product Owner from the Retrospective is a distractor. Stakeholders do not attend — the Retrospective is the team's private inward look, in contrast to the Sprint Review, which includes stakeholders. The Scrum Master participates as a peer and ensures the event is positive and productive, but does not own or dominate it.

Common Exam Traps

The Sprint Retrospective generates a recognizable family of PSM I distractors. Watch for these:

• It is not optional, even for high-performing teams. It is a formal event of every Sprint; "we ship well, so we can skip it" is wrong.
• It is not a blame session. It focuses on the process and system, not on individuals' faults. An answer that frames it as documenting who missed commitments is wrong.
• It looks inward at the team's way of working. Product and Product Backlog topics belong to the Sprint Review. Routing stakeholder product feedback here is a misroute.
• It is not run by the Scrum Master as a boss. The Scrum Master facilitates; the whole team owns the improvements.
• Improvements should be actionable and specific, not vague intentions. A good test: could the team start the improvement next Sprint and tell whether it worked?

Why It Matters

The Retrospective is how Scrum's empiricism turns inward on the team itself. Without it, the team would inspect the product (in the Review) and progress (in the Daily Scrum) but never systematically improve how it works. The result over time is compounding effectiveness: small, concrete changes each Sprint that raise quality and reduce friction. On the exam, anchor on the phrase "increase quality and effectiveness" and the inspection targets "individuals, interactions, processes, tools, and the Definition of Done," and most Retrospective items resolve cleanly.

Worked Scenario: A 'Perfect' Sprint

" The answer is no. The Retrospective is a formal event of every Sprint, and even a smooth Sprint surfaces small improvements: a tool that almost failed, a hand-off that was slow, an assumption that nearly led astray. The team can still ask what made the Sprint go well and how to reinforce it. Effectiveness is not a fixed ceiling, and continuous improvement is precisely the empirical habit the Retrospective protects. Skipping it because things "feel fine" is the trap.

Connecting the Retrospective to the Definition of Done

One subtle but testable detail in the 2020 Scrum Guide is that the Definition of Done is explicitly in scope for the Retrospective. If the team's Definition of Done is too weak, the Increment may be "Done" on paper but low quality in practice; the Retrospective is where the team strengthens the Definition of Done so future Increments are genuinely releasable. Where an organization imposes a baseline Definition of Done across teams, individual teams must meet at least that standard and may add to it — and the Retrospective is the natural place to tighten the team's own additions.

This links the Retrospective directly to the Increment's transparency: a better Definition of Done means inspection at the Sprint Review is more honest. So an answer that proposes improving the Definition of Done during the Retrospective is consistent with the Guide, not a misroute.