During Sprint Planning, a hardware test engineer on the Developers says the team can commit to fewer Product Backlog items this Sprint because of an unexpected certification retest. The Scrum Master overhears and tells the Developers they must keep the original number of items to avoid disappointing the Product Owner. Is this an appropriate use of the Scrum Master accountability?

The 2020 Scrum Guide is explicit that the Developers are the ones who select how much Product Backlog work they believe they can complete during the Sprint, forecasting through Sprint Planning based on their own capacity and information like an upcoming certification retest. The Scrum Master overriding that forecast to preserve a number contradicts self-management and misapplies the Scrum Master accountability, which is to coach and support the process, not to dictate output. The first wrong option describes a real Scrum Master responsibility — supporting the Scrum Team's effectiveness — but effectiveness is served by protecting the Developers' forecasting authority, not overruling it, so that framing is backwards here. 'Protecting the Sprint Goal' also misfires: a Sprint Goal describes the purpose of the Sprint, not a fixed item count, and a team can still meet a Sprint Goal with fewer items if the plan adapts. The Product Owner doesn't hold this authority either — they collaborate on what's most valuable, but item selection based on capacity sits with the Developers. A good operational check: whenever someone outside the Developers is dictating the exact number of Sprint Backlog items, that's a signal self-management has been quietly overridden.