Shift a Sprint Review from a Demo to a Working Session

WHAT THIS TESTS: This question tests your understanding of Scrum principles, specifically that the Sprint Review is a formal opportunity for inspection and adaptation, not just a demo. The interviewer wants to see if you can move beyond your coding tasks and take ownership of the process, collaborating with the Product Owner (PO) and stakeholders to improve product outcomes. They are looking for proactive, collaborative problem-solving, not just complaining about bad meetings.

A GOOD ANSWER COVERS: A strong answer outlines specific actions an engineer can take. First, partner with the PO before the review to structure it as a working session, not a presentation. This includes agreeing on what key questions to ask stakeholders. Second, during the review, frame the work shown in the context of the Sprint Goal and what was learned, not just what was built. Third, actively solicit feedback by asking open-ended questions like, "How does this new functionality change our understanding of what's needed next?" or "Based on this, what's the most valuable thing we could do in the next Sprint?". Fourth, ensure the discussion leads to tangible changes in the Product Backlog, making the adaptation concrete.

COMMON WRONG ANSWERS: A major red flag is blaming others. Answers like "That's the PO's job" or "Our stakeholders just don't care" show a lack of ownership and a junior mindset. Another weak answer is suggesting purely technical solutions, like building a better demo environment, without addressing the collaborative and strategic purpose of the meeting. Finally, simply stating "we should get feedback" is too generic; a senior answer describes how to elicit that feedback and what to do with it.

LIKELY FOLLOW-UPS: "What if the Product Owner is resistant to this change?" (Answer should focus on influence, data, and starting small). "What if stakeholders are disengaged and don't provide feedback?" (Answer should cover inviting the right people, setting expectations, and asking better questions). "How do you measure if the Sprint Review has become more effective?" (Answer should mention a higher rate of Product Backlog adaptation, clearer Sprint Goals, and qualitative feedback from the team).

ONE CONCRETE EXAMPLE: "In my last project, our reviews were passive demos. I suggested to our PO that for the next review, instead of just showing the UI, we should present two key metrics the new feature was supposed to impact. We showed the Increment, then put up a slide with the current baseline for those metrics and asked the stakeholders: 'Based on what you've seen, do we still believe this is the best way to move these numbers? What's our next most valuable step?' This shifted the conversation from 'looks nice' to a strategic discussion, and we re-ordered two items in the backlog right there in the meeting."