What is the purpose of Sprint Review vs. Sprint Retrospective?

WHAT THIS TESTS: This question tests your understanding of Scrum's empirical nature, specifically the principles of inspection and adaptation. The interviewer wants to see if you can distinguish between the two critical feedback loops: the loop for the product and the loop for the process. The Sprint Review is about inspecting the what (the Increment) to adapt future product direction. The Sprint Retrospective is about inspecting the how (the team's effectiveness) to adapt the team's process. Separating these concerns is fundamental to a healthy Scrum implementation.

A GOOD ANSWER COVERS: A complete answer explains the distinct purpose, audience, and outcome of each event. First, define the Sprint Review: its purpose is to inspect the Sprint's outcome (the Increment) and adapt the Product Backlog. Its audience is the entire Scrum Team plus key stakeholders invited by the Product Owner. The outcome is a revised Product Backlog that reflects new insights. Second, contrast this with the Sprint Retrospective: its purpose is to plan ways to increase quality and effectiveness. Its audience is strictly the Scrum Team (Developers, Product Owner, Scrum Master). The outcome is a list of actionable improvement items for the next Sprint.

COMMON WRONG ANSWERS: A frequent mistake is calling the Sprint Review a "demo." While a demonstration of the work is part of it, the primary purpose is a two-way conversation to gather feedback, not a one-way presentation. Another red flag is treating the Review as a formal "sign-off" from stakeholders; the Product Owner remains the sole decision-maker for the Product Backlog. For the Retrospective, a major error is including stakeholders. This prevents psychological safety and honest discussion about the team's internal challenges. Finally, describing the Retrospective as just a venting session without a concrete, actionable plan for the next Sprint shows a misunderstanding of its purpose.

LIKELY FOLLOW-UPS: Be ready for questions like "What is the Scrum Master's role in each meeting?" or "How do you handle a stakeholder who tries to dictate solutions during a Sprint Review?" For the latter, a good response is to thank them for the input, note it, and explain that the Product Owner will prioritize it accordingly in the Product Backlog. Another follow-up could be, "What happens if the team identifies a major process issue during the Sprint Review?"

ONE CONCRETE EXAMPLE: An outcome from a Sprint Review could be stakeholders observing that a new feature is less intuitive than expected. The Product Owner then adds a new user story to the Product Backlog to refine the UI based on that feedback. In contrast, an outcome from a Sprint Retrospective could be the team identifying that their code reviews are taking too long. They decide to experiment with a 2-hour timebox for all reviews in the next Sprint and add this as an action item to their Sprint Backlog.