September 7, 2026 · 8 min read
TL;DR: Agile ceremony options in this bank are keyed 50 times and used as distractors 115 times. Retrospectives: 21 keyed, 46 distractors. Standups: 9 and 27. Sprint reviews: 7 and 19. Planning: 9 and 17. Refinement: 4 and 6. Not one of the five is right more often than wrong, because the standard question shape offers you the correct event alongside two or three that sound equally procedural. Naming the ceremony gets you nothing. Knowing what each one is for gets you the mark.
A candidate who has learned the Scrum events feels well prepared for these questions and then gets them wrong at a surprising rate. The reason is structural. When the answer is a ceremony, the other three options are usually also ceremonies, so recall does not discriminate between them. Only purpose does.
We measured every ceremony option across the bank. Fifty keyed, 115 distractors. Here is what separates them.
One sentence each, and the exam holds these lines strictly.
| Event | What it inspects | Who it belongs to |
|---|---|---|
| Sprint review | The increment, against what stakeholders wanted | The team and its stakeholders |
| Retrospective | The team's own way of working | The team, privately |
| Daily standup | Progress toward the sprint goal and today's impediments | The team |
| Sprint planning | What the team will commit to next | The team and product owner |
| Backlog refinement | The order and readiness of what is waiting | The product owner |
The cleanest test of those distinctions in the bank: a board member on a strategic programme wants to attend a meeting to see how delivery of the project scope is progressing. The options invite them to the next sprint review, a separate demonstration, the next retrospective, or the next daily standup.
The sprint review is keyed, and each distractor fails for a different and instructive reason. A separate demonstration duplicates an event the team already holds and hides the real one. The retrospective is the team's private inspection of its own working, and a board member in the room changes what people are willing to say. The standup is 15 minutes for the team to coordinate its own day, not a status report for visitors. All three are real events. Only one of them answers the question the board member is asking.
In this bank, almost never, and two questions make the point from opposite directions.
An agile team has wrapped its third sprint, delivered everything it committed to, velocity is steady, stakeholders are pleased, no blockers. Some members suggest skipping the retrospective this time to free the time for sprint planning. The options let you skip it, run a quick 15-minute version, hold the full retrospective as planned, or replace it with a celebration.
The full retrospective is keyed. A sprint that went well is the most useful one to examine and the most likely to be skipped, because what made it work is rarely obvious: a story broken down better than usual, a dependency cleared early, an absence of interruptions nobody noticed. Unless the team names it, the success is not repeatable and the practice quietly lapses.
The mirror case is more interesting. A team member complains that retrospectives keep producing the same outcomes and proposes cancelling them or holding them less often. The options lengthen the sprint timebox, hold retrospectives every other sprint, put it to a vote and skip them if everyone agrees, or keep the cadence and reflect on how to make them more relevant and actionable.
The last one is keyed, and the explanation is unusually generous to the complainer: the complaint is worth taking seriously even though the proposed remedy is wrong. A retrospective that keeps producing the same outcomes is a retrospective whose outputs are not being acted on, and a team watching its own improvements go nowhere will correctly conclude the meeting is theatre. Keep the cadence, fix the meeting.
Common trap: using the retrospective as a bin for anything reflective. A hybrid team works through a hard sprint, meets the sprint goal, and at the sprint review the product owner comes back with a long list of changes. One option has the team take it to the retrospective and work out how to avoid changes like these in future. That sounds like continuous improvement. It is the distractor, and the reason is sharp: treating stakeholder feedback as something to be prevented contradicts the entire point of the review. The keyed answer has the product owner take the changes into backlog refinement, where a batch of changes gets weighed against everything else waiting before any of it is built. Dropping them straight into the next sprint skips the prioritisation, and a change control board has no part in the sprint cycle at all.
Ask what is being inspected, and who owns the answer.
If the thing under examination is the product, it is a review. If it is how the team works, it is a retrospective. If it is today's obstacles, it is the standup. If it is what comes next and in what order, it is refinement, and the product owner decides. Almost every ceremony distractor in this bank fails one of those four tests, and you can usually apply them faster than you can recall the event definitions.
That is why the count matters less than the reasoning. Fifty keyed against 115 distractors tells you not to trust a ceremony option on sight. Knowing what each event inspects tells you which one to trust, which is the difference between recognising an answer and being able to defend it.
Why are agile ceremonies wrong answers so often on the PMP exam? Because the question writers put the right event and two or three plausible wrong ones in the same option set. Retrospectives are keyed 21 times against 46 as distractors, sprint reviews 7 against 19, standups 9 against 27, planning 9 against 17, refinement 4 against 6. Every one is wrong more often than right.
What is the difference between a sprint review and a retrospective on the exam? The review is about the product, the retrospective about the team's own way of working. When a board member wants to see how delivery of scope is progressing, the keyed answer invites them to the sprint review; inviting them into the retrospective is a distractor.
Can a team skip a retrospective after a successful sprint? No. The keyed answer holds the full retrospective as planned. A sprint that went well is the most useful one to examine and the most likely to be skipped, because what made it work is rarely obvious.
Where do changes from a sprint review go? Into backlog refinement with the product owner, so they can be weighed against everything else waiting. Dropping them straight into the next sprint skips the prioritisation, and a change control board has no part in the sprint cycle.
PMP Practice's 2,141 questions are re-certified against PMBOK 8 and the July 2026 exam content outline, with every wrong answer explained rather than just marked wrong, which on ceremony questions means learning why the other three events were plausible in the first place. Start the free 20-question sample — no card, no signup required to try it.
Why are agile ceremonies wrong answers so often on the PMP exam?
Because the question writers put the right event and two or three plausible wrong ones in the same set of options. Across this bank, retrospectives are keyed 21 times against 46 as distractors, sprint reviews 7 against 19, daily standups 9 against 27, planning 9 against 17, and backlog refinement 4 against 6. Every one of them is wrong more often than right, which means recognising the ceremony is not enough.
What is the difference between a sprint review and a retrospective on the exam?
The review is about the product and the retrospective is about the team's own way of working. When a board member wants to see how delivery of scope is progressing, the keyed answer invites them to the sprint review. The retrospective is the team's private inspection of how it works, and inviting an outsider into it is a distractor.
Can a team skip a retrospective after a successful sprint?
No, and the exam is direct about it. In a question where the team delivered everything it committed to and members suggest skipping the retrospective, the keyed answer holds the full retrospective as planned. A sprint that went well is the most useful one to examine and the most likely to be skipped, because what made it work is rarely obvious.
Where do changes from a sprint review go?
Into backlog refinement with the product owner. A batch of changes has to be weighed against everything else waiting in the backlog before any of it is built. Dropping them straight into the next sprint skips the prioritisation, and a change control board has no part in the sprint cycle.