At a Sprint Review, the hardware team and firmware team disagree in front of stakeholders about which team's defect caused a robot's arm motor to stall during demonstration. What should the Scrum Master do in the moment?
Select an answer to reveal the explanation.
Short Explanation
A Sprint Review exists to inspect the product and gather feedback, not to stage a public inquest into whose defect it was. The smoothest move is to acknowledge the issue plainly, keep the room focused on the Increment and stakeholder input, and take the "why" conversation somewhere else afterward.
Full Explanation
The mechanism is protecting the purpose of the event: Sprint Review is for inspecting the Increment and adapting the Product Backlog based on stakeholder feedback, and a live blame investigation derails both goals while wasting the stakeholders' time. Naming a responsible engineer on the spot turns a collaborative inspection into a public shaming exercise, which damages trust with the very people whose honest work the event depends on. Canceling the Review entirely overreacts to one defect and denies stakeholders the chance to give feedback on everything else that is working, throwing away value rather than preserving it. Directing the Product Owner to publicly blame a team misuses the Product Owner's role — they're accountable for value and Product Backlog decisions, not for adjudicating interteam disputes in front of an audience — and it would badly damage both teams' trust in leadership. A solid operational check: confirm the defect investigation actually happens afterward, ideally in a joint session between the two teams, so the deferral wasn't just a way to avoid the topic altogether.