What is the primary difference between Sprint Review and Sprint Retrospective?

WHAT THIS TESTS: This question checks if you understand that Scrum has two separate inspection and adaptation cycles at the end of a Sprint. One cycle focuses on the product and involves outsiders; the other focuses on the team process and stays internal. Interviewers want to see that you do not collapse these into a generic meeting and that you know who must attend, what is inspected, and what artifact or plan is adapted.

A GOOD ANSWER COVERS: First, purpose. Sprint Review inspects the Increment and progress toward the Product Goal; it adapts the Product Backlog. Sprint Retrospective inspects the Scrum Team's own process, interactions, and tools; it adapts how the team works. Second, participants. Sprint Review includes the Scrum Team plus key stakeholders. Sprint Retrospective includes only the Scrum Team; stakeholders are not present. Third, tone and output. Sprint Review is collaborative and forward-looking, often resulting in backlog changes. Retrospective is honest and safe, resulting in one or more improvement items for the next Sprint. Fourth, timebox. Both are timeboxed to a maximum of four hours for a one-month Sprint; for shorter Sprints they are usually shorter.

COMMON WRONG ANSWERS: Calling the Sprint Review a demo or status report is a red flag because it misses the adaptation of the Product Backlog and the required stakeholder collaboration. Saying stakeholders attend the Retrospective shows you do not understand the need for a safe space for the Scrum Team to inspect itself. Claiming the Review is for the Product Owner alone to present work ignores the empirical requirement that developers and stakeholders inspect together. Confusing the two events into one generic feedback session suggests you have not read the Scrum Guide carefully.

LIKELY FOLLOW-UPS: The interviewer may ask how to handle stakeholders who demand to attend the Retrospective; the correct response is to invite them to the Review instead and protect the Retrospective boundary. They may ask what happens if the team skips the Retrospective; you should explain that inspection without adaptation is pointless and process debt accumulates. They may also ask for an example of a Review outcome versus a Retrospective outcome.

ONE CONCRETE EXAMPLE: Imagine a team finishes a Sprint with a new payment feature. In the Sprint Review, the team demonstrates the feature to the finance stakeholder, who realizes the refund flow is missing. The group adapts the Product Backlog by adding refund stories for the next Sprint. In the Sprint Retrospective, the Scrum Team notes that the payment feature required three days of rework because code reviews were delayed. They adapt by adding a team working agreement to complete reviews within four hours. Same Sprint, two different inspections, two different adaptations.