Sprint Review vs. Sprint Retrospective: Purpose and Participants

WHAT THIS TESTS: This question tests your practical, not just theoretical, understanding of Scrum's feedback loops. The interviewer is checking if you can distinguish between inspecting the PRODUCT versus inspecting the PROCESS. For a senior candidate, this means articulating the 'why' behind the structure of these meetings, especially regarding participants and psychological safety.

A GOOD ANSWER COVERS: A strong answer defines the two events across three distinct axes. First, PURPOSE: the Review is about inspecting the Increment and adapting the Product Backlog (the 'what'). The Retrospective is about inspecting the team's effectiveness and planning improvements (the 'how'). Second, PARTICIPANTS: the Review includes the Scrum Team and key stakeholders. The Retrospective is strictly for the Scrum Team (Product Owner, Scrum Master, and Developers) only. Third, OUTCOMES: the Review's main outcome is a revised Product Backlog. The Retro's main outcome is at least one actionable process improvement for the next Sprint.

COMMON WRONG ANSWERS: A major red flag is suggesting stakeholders should attend the Retrospective. This undermines the psychological safety required for the team to have a candid discussion about its internal workings. Another common mistake is calling the Sprint Review a 'demo' or a 'sign-off' meeting. It is a working session for collaboration and feedback, not a formal gate. Finally, describing the Retrospective as just a venting session without a focus on creating specific, actionable improvements for the next Sprint shows a lack of maturity.

LIKELY FOLLOW-UPS: A common follow-up is, 'How would you handle a senior stakeholder who insists on joining the Retrospective?' This tests your ability to uphold process and explain its value. Another is, 'What do you do in a Sprint Review if the team didn't complete an Increment?' This tests your understanding of transparency. Expect behavioral questions like, 'Tell me about the most effective process improvement that came out of a Retrospective you were in.'

ONE CONCRETE EXAMPLE: For a two-week sprint, the Sprint Review might be a 2-hour meeting. The team presents a new checkout flow. Stakeholders from marketing and finance provide feedback, noting that the tax calculation is confusing. The Product Owner adds 'Simplify tax display in checkout' to the Product Backlog. The Sprint Retrospective would be a 90-minute meeting afterward. Only the Scrum Team attends. They discuss that vague requirements for the tax feature caused rework. They decide to implement a 'requirements readiness' checklist as their process improvement for the next Sprint.