Sprint Review vs Retrospective: purpose, focus, and audience

WHAT THIS TESTS: This question tests whether you understand Scrum's empirical pillars at the Sprint boundary. Specifically, it checks if you can distinguish the product-facing inspection loop from the process-facing inspection loop, and whether you know the correct audience and purpose for each event.

A GOOD ANSWER COVERS: A strong answer hits four points in order. First, the Sprint Review is where the Scrum Team and stakeholders inspect the Increment and progress toward the Product Goal, then adapt the Product Backlog. Second, the Sprint Retrospective is where the Scrum Team inspects itself regarding how the Sprint went with respect to individuals, interactions, processes, tools, and the Definition of Done, then creates a plan for improvement. Third, the audience differs because stakeholders join the Review, while the Retrospective is attended only by the Scrum Team. Fourth, the focus differs because the Review is about what was built and what to build next, while the Retrospective is about how the team works together.

COMMON WRONG ANSWERS: Red flags include calling the Review a demo or status report rather than an inspection and adaptation event. Another red flag is saying stakeholders attend the Retrospective. Some candidates claim the Review is only for the Product Owner to approve work, or they describe the Retrospective as a place to show the Increment to the team. Conflating both events into a single generic lessons-learned meeting also signals weak Scrum knowledge.

LIKELY FOLLOW-UPS: An interviewer might ask how you would handle a stakeholder requesting new scope during the Sprint Review. They might ask what metrics or data the team should inspect in a Retrospective. They could ask why the Scrum Guide separates these into two events instead of combining them. Another follow-up is how the Definition of Done relates to the Retrospective.

ONE CONCRETE EXAMPLE: Imagine a team just delivered a new checkout flow. In the Sprint Review, they walk stakeholders through the live Increment, review early conversion data, and learn that users want a guest checkout option. The Product Owner adds that item to the Product Backlog. In the Sprint Retrospective, the team realizes their code reviews took too long because of timezone gaps. They adapt by scheduling overlapping hours and updating their working agreement. The same Sprint produced two distinct inspection outcomes: one shaped the product, the other shaped the team.