The Sprint Retrospective is consistently one of the most misrepresented events on the PSM I and PSPO I exams. Candidates either memorize a surface-level summary (“it’s the meeting where the team discusses what went well and what didn’t”) or carry forward a misconception from outdated study materials — most commonly, that the Product Owner doesn’t attend. Both of those positions will cost you points. This article walks through exactly what the 2020 Scrum Guide says, where the exam questions focus, and the specific traps that trip up otherwise well-prepared candidates.
Where the Retrospective Sits in the Sprint
Before getting into the content, the sequence matters. The Sprint Retrospective is the final event of the Sprint. It follows the Sprint Review and, per the Scrum Guide, it concludes the Sprint. That ordering — Review then Retrospective — is itself a testable fact, and candidates occasionally get it backwards.
The logic behind the sequence is sound: the team first inspects the product (Sprint Review, with stakeholders), then inspects themselves (Sprint Retrospective, Scrum Team only). What the team learns about the product and stakeholder needs in the Review can directly inform what they want to improve about their process in the Retrospective.
What the Scrum Guide Actually Says the Purpose Is
The 2020 Scrum Guide states: “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”
Read that carefully. The purpose isn’t to vent, it isn’t to assign blame, and it isn’t merely to catalogue what went wrong. It is to plan ways to improve. That word — plan — is load-bearing. The event has a concrete output: improvements identified, the most impactful ones committed to, and the most urgent potentially added to the Sprint Backlog for the very next Sprint.
Many candidates describe the Retrospective’s purpose as “inspect and adapt the process,” which is broadly correct but too vague to answer exam questions precisely. The Scrum Guide specifies what gets inspected and what gets adapted. Knowing those specifics is what separates an 85% score from a 70% score on this topic.
What the Scrum Team Actually Inspects
The Scrum Guide is explicit: “The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.”
This is a list worth memorizing in full — not because the exam will always ask you to reproduce it, but because it clarifies the scope of the event. The Retrospective is not limited to process. It covers:
- Individuals — how each person is working, their skills, their engagement
- Interactions — how people are collaborating and communicating with each other
- Processes — the practices and workflows the team is using
- Tools — the software, boards, or instruments supporting the work
- The Definition of Done — whether the current DoD is appropriate and whether it should be strengthened
That last item — the Definition of Done — appears in several PSM I and PSPO I questions in a form like: “When is the appropriate time for the Scrum Team to review and potentially update the Definition of Done?” The answer the Scrum Guide supports is the Sprint Retrospective. If you’ve studied the PSM I exam content on the Definition of Done, this connection is one you should have in your notes.
The Scrum Guide also notes: “Assumptions that led them astray are identified and their origins explored.” This is a subtle but important point. The Retrospective isn’t just a forward-looking planning meeting — it’s an act of diagnosis. Teams should understand why problems occurred, not just that they occurred.
Who Attends — and Why This Is a Major Exam Trap
Here is where a significant number of candidates lose points, and where a lot of practice test material — including some widely shared study notes — gets it wrong.
The 2020 Scrum Guide is unambiguous: the Sprint Retrospective is a Scrum Team event. The Scrum Team consists of the Developers, the Product Owner, and the Scrum Master. All three attend. The Product Owner does not sit this one out.
This misconception has a history. In earlier versions of the Scrum Guide (pre-2020), the Retrospective language was written differently and some practitioners interpreted it as a Developers + Scrum Master event. The 2020 revision made the Scrum Team’s collective accountability explicit throughout, including in the Retrospective. If you’re using study materials that were written before 2020 or that haven’t been updated since, you may be learning the wrong answer.
On the exam, you may see questions like: “Who participates in the Sprint Retrospective?” or scenario questions where the Product Owner is absent from a Retrospective and you’re asked whether this is appropriate. Per the current Scrum Guide, it is not.
External stakeholders, however, do not attend the Sprint Retrospective. The event is for the Scrum Team. If someone needs stakeholder input to inform improvements, that’s a topic for a different conversation, not an invitation to bring stakeholders into the Retrospective itself.
The Timebox
The Sprint Retrospective is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter — the Scrum Guide uses the phrase “usually shorter” rather than specifying a formula, because proportional reduction is a reasonable guideline but not a rigid rule.
The timebox is a maximum, not a target. A team running a two-week Sprint does not need to fill 90 minutes of Retrospective just because that’s proportionally “correct.” The team decides when the work of the event is done, within the timebox.
On the exam, timebox questions sometimes appear in comparison form: “What is the maximum timebox for the Sprint Retrospective for a one-month Sprint?” The answer is three hours. Compare with Sprint Planning (eight hours maximum) and Sprint Review (four hours maximum) — knowing all three timeboxes and being able to distinguish them quickly is worth the five minutes it takes to memorise them.
What Happens to the Improvements the Team Identifies
The Scrum Guide says: “The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.”
Two exam-relevant points are packed into those sentences.
First: not all improvements get added to the Sprint Backlog. The Scrum Guide says the team identifies the “most helpful changes” and that the “most impactful” ones are addressed as soon as possible. The emphasis is on prioritisation — you don’t catalogue every possible improvement and carry it forward indefinitely. The team picks the most valuable ones to act on.
Second: when improvements are added to a backlog, they go to the Sprint Backlog, not the Product Backlog. This is a distinction the exam tests. Process improvements are the Scrum Team’s work — they belong in the Sprint Backlog. Adding process improvements to the Product Backlog would conflate two distinct concerns: product development work and team improvement work.
A typical exam question in this area looks like: “At the Sprint Retrospective, the Scrum Team identifies some important process improvements. What should the team do?” Options will usually include adding improvements to the Product Backlog, adding them to the Sprint Backlog, having the Scrum Master implement them unilaterally, or waiting until the next Retrospective. The Scrum Guide-aligned answer is that the most impactful improvements may be added to the Sprint Backlog for the next Sprint.
The Scrum Master’s Role in the Retrospective
The Scrum Master participates in the Retrospective as a peer member of the Scrum Team — not as a facilitator standing outside the group. The Scrum Guide describes the Scrum Master as accountable for ensuring that all Scrum events take place and are “positive, productive, and kept within the timebox.” For the Retrospective specifically, the Scrum Master is also a participant in the inspection and planning of improvements that affect how they serve the team.
Some exam questions probe whether candidates understand servant leadership in the context of the Retrospective. The Scrum Master does not own the list of improvements, does not unilaterally decide which ones to implement, and does not report the outcomes to management. The improvements belong to the Scrum Team collectively.
Where Candidates Lose Points on This Topic
Having worked through the Scrum Guide specifics, here are the specific errors that appear repeatedly in practice test results:
Getting the sequence wrong
Some candidates place the Retrospective before the Sprint Review, or describe it as happening “between Sprints.” The Retrospective is part of the Sprint. It follows the Sprint Review. It concludes the Sprint. The next Sprint begins immediately after.
Excluding the Product Owner
As covered above, the Product Owner is part of the Scrum Team and attends the Retrospective. If a question presents a scenario where the Product Owner skips the Retrospective, the Scrum Guide-aligned response is that this is not in keeping with how Scrum defines the event.
Mis-stating the purpose
Describing the Retrospective’s purpose as “identifying what went wrong” or “reviewing team performance” is incomplete and will lead you to pick wrong answers on purpose-identification questions. The Scrum Guide’s phrasing — “plan ways to increase quality and effectiveness” — is more specific and action-oriented. Anchor on that.
Sending improvements to the wrong backlog
The Sprint Backlog is where process improvement items belong, not the Product Backlog. The Product Backlog is for product-related work; the Sprint Backlog is a plan for the Developers for the upcoming Sprint, and including a process improvement there makes it visible and actionable within the next Sprint.
Forgetting that the Definition of Done is in scope
The Retrospective is the primary event where the Scrum Team can revisit and strengthen the Definition of Done. Many candidates treat the DoD as something created once and rarely revisited. The Scrum Guide explicitly lists it as one of the things the Scrum Team inspects during the Retrospective.
A Worked Scenario Question
Here’s the kind of question that catches candidates out:
During the Sprint Retrospective, the Scrum Team agrees that they should improve their Definition of Done and adopt a new automated testing approach. The Scrum Master suggests adding the testing setup work to the Product Backlog so it can be prioritized. Is this appropriate?
The answer is no, and the reasoning is precise: the work to set up the automated testing approach is an improvement to the Scrum Team’s way of working, not a product feature or product-related work item. It belongs in the Sprint Backlog for the next Sprint — not the Product Backlog. Additionally, the Scrum Master does not unilaterally decide where items go; the Scrum Team makes this decision together. The suggestion to add it to the Product Backlog conflates product work with team improvement work, which muddies transparency for both.
Notice also that the question embeds two issues — placement of the item and the Scrum Master’s decision-making authority — in a single scenario. Exam questions frequently test multiple concepts simultaneously in this way. You need to catch both.
How to Study This Topic Effectively
The Sprint Retrospective section of the Scrum Guide is short — less than 200 words. Read it several times and pay attention to every word choice. “Plan” (not “discuss”). “Quality and effectiveness” (not “problems”). “May even be added to the Sprint Backlog” (not “must be added”). “The Scrum Team” (not “the Developers”).
When working through practice questions on this topic, flag any question where the correct answer surprised you. The Retrospective is an event where exam writers exploit the gap between how most teams actually run their retrospectives and what the Scrum Guide prescribes. Real-world experience can work against you here if you’ve worked on teams where the Product Owner didn’t attend, or where improvements were tracked on a separate “process backlog,” or where the Scrum Master facilitated from a separate flip chart and then emailed a summary to the team.
None of those practices are wrong in a practical sense — teams adapt their retrospectives constantly. But on the PSM I and PSPO I exams, you’re being tested on the Scrum Guide, and the Scrum Guide defines the floor for how the event should work.
If you want to test your understanding of the Retrospective alongside the rest of the Scrum events and artifacts, the free PSM I practice test covers event-related questions with explanations tied to the Scrum Guide. For PSPO I candidates, the free PSPO I practice test tests product-side scenarios where the Retrospective intersects with Product Backlog management and Definition of Done decisions.
For deeper practice with full scenario-based question sets — including questions that combine Retrospective concepts with team dynamics, backlog management, and Scrum Master accountability — the PSM I Exam Simulator includes 800+ questions with Scrum Guide-referenced explanations. The PSPO I Exam Simulator covers the same ground from the Product Owner accountability perspective.