During a Sprint Review, the Product Owner sharply criticizes a Developer's companion-app work in front of retail stakeholders, embarrassing the Developer. What should the Scrum Master do after the event?
Select an answer to reveal the explanation.
Short Explanation
Public callouts feel efficient in the moment, but they cost you something you can't easily buy back: the team's willingness to show unfinished work honestly. A private, one-on-one conversation lets the Scrum Master coach the feedback habit without creating a second uncomfortable moment on top of the first.
Full Explanation
The mechanism here is that Sprint Review only works if Developers feel safe showing real, sometimes imperfect, work to stakeholders — public humiliation teaches people to over-polish or hide problems next time, which quietly poisons transparency. Coaching the Product Owner privately addresses the behavior directly while preserving the Product Owner's standing with the team, since a public correction in the same meeting would just create a second embarrassing spectacle layered on the first. Adding a note to avoid the feature area sidesteps the actual issue — it's not about the work itself, it's about how feedback was delivered — and does nothing to prevent a repeat. Treating the criticism as normal and needing no follow-up ignores the Scrum Master's accountability to the whole Scrum Team, not just to protecting events from the outside; part of serving the Product Owner is helping them interact effectively with Developers and stakeholders. A reasonable operational check: in the next Sprint Review, notice whether Developers are volunteering rough edges and open questions again, or have gone quiet and defensive — that tells you whether trust actually recovered.