A retail partner emails the Scrum Master directly asking to add a new feature to the current Sprint's Sprint Backlog because it would help close a deal. The Scrum Master forwards the request to the Developers with instructions to add it immediately. What went wrong here?
Select an answer to reveal the explanation.
Short Explanation
A stakeholder request landing in someone's inbox doesn't turn into a Sprint Backlog change just because that person forwards it with an instruction attached. The Scrum Master isn't the gate for adding work — that's a conversation between the Product Owner, who owns value and priority, and the Developers, who own the plan and the capacity to absorb it.
Full Explanation
Changing what's in the Sprint Backlog mid-Sprint is a joint call: the Product Owner weighs whether the new work is valuable enough to negotiate in, and the Developers assess whether their plan and capacity can absorb it without threatening the Sprint Goal. The Scrum Master directing the Developers to add the item skips both of those checks and exercises authority the Scrum Master accountability does not include — the Scrum Master facilitates and coaches, but does not decide what goes into the Sprint Backlog. Saying nothing went wrong ignores that stakeholder requests are meant to flow into Product Backlog management, not be injected directly into an active Sprint by whoever received the email. Suggesting the retail partner bypass the Scrum Master and go straight to the Developers is also off: Developers deciding unilaterally to add stakeholder-driven scope mid-Sprint has the same problem, just with a different messenger, since the Product Owner's value judgment is still missing. Routing it to hardware instead doesn't address the actual issue, which is who gets to authorize a Sprint Backlog change. The operational check: any new work entering an active Sprint should be traceable to a Product Owner and Developers conversation, not a single person's forwarded instruction.