Partway through a Sprint, the app Developers realize their original plan for reworking the pairing screen won't work and want to change their approach to the remaining Sprint Backlog items. Who decides whether that change happens?
Select an answer to reveal the explanation.
Short Explanation
The Sprint Backlog is the Developers' own working plan, not a contract someone else signs off on. If the map they drew at the start of the Sprint stops matching the terrain, they're the ones who get to redraw it — that's what it means for the plan to belong to them.
Full Explanation
The Sprint Backlog — the Sprint Backlog items plus the plan for delivering them and achieving the Sprint Goal — is owned and continuously updated by the Developers as they learn more during the Sprint. Discovering mid-Sprint that an approach won't work is exactly the situation self-management is built for: the Developers adjust their plan as needed, as long as the Sprint Goal itself isn't abandoned. Requiring Scrum Master approval misreads the role entirely; the Scrum Master has no sign-off authority over the Developers' internal plan, only a responsibility to help protect the Sprint Goal and remove obstacles. Requiring Product Owner approval confuses two different things — the Product Owner cares about what value is delivered and can renegotiate scope with the Developers if the Sprint Goal is genuinely threatened, but a change in implementation approach for backlog items already in the Sprint doesn't require their sign-off. Involving the program manager pulls the decision outside the Scrum Team entirely, which conflicts with the Developers' accountability for their own work. An operational check: ask whether the change threatens the Sprint Goal — if not, it's a normal, expected Developer-level adjustment; if the Goal itself is at risk, that's when a conversation with the Product Owner becomes appropriate.