Sprint Retrospective: What's the output and what happens next?

WHAT THIS TESTS: This question tests your understanding of Scrum as a framework for continuous, empirical improvement, not just a set of meetings. The interviewer wants to see if you connect the retrospective's discussion to concrete, trackable action. They are listening for a bias for action and a recognition that process improvements are formal work, not just a "nice to have" that might get forgotten.

A GOOD ANSWER COVERS: A strong answer covers three key points in order. First, the primary output is a small number of specific, actionable improvement items, not just a list of complaints or observations. Second, the goal is to identify the single most impactful improvement the team can tackle in the next Sprint. Third, this chosen improvement item is formally added to the Sprint Backlog for the upcoming Sprint. This makes it visible, ensures it's treated as committed work, and creates accountability.

COMMON WRONG ANSWERS: A major red flag is describing a process that ends with passive documentation, like "we write up the notes and put them in Confluence." This shows a lack of action-orientation. Another common mistake is saying the output is simply a list of "what went well" and "what went wrong," which is the input to the discussion, not the actionable output. Stating that the Scrum Master is solely responsible for implementing the changes is also incorrect; the improvement is added to the backlog for the entire Scrum Team to own and execute. Vague answers like "we agree to try harder" are a sign of inexperience.

LIKELY FOLLOW-UPS: Be ready for "How do you handle an improvement item that's too big for one Sprint?" (Answer: Break it down into smaller, deliverable pieces, just like a feature epic). Another is "How do you measure if the improvement was successful?" (Answer: Define a metric beforehand, e.g., "reduce build times from 15 minutes to under 7 minutes"). They might also ask for an example of a time a retro failed and why.

ONE CONCRETE EXAMPLE: During a retro, the team identifies that PRs are taking >24 hours to get a first review, blocking developers. The output is a specific, actionable improvement: "Experiment with a 2-hour 'focus block' from 10am-12pm where all engineers prioritize code reviews over new coding." A story is created for this task and added to the top of the next Sprint's backlog with an acceptance criterion like "Average time-to-first-review decreases by 50%." This makes the improvement a formal, non-negotiable part of the next Sprint's work.