A support-operations lead emails the Developers directly, asking them to bump a battery-overheating bug fix above everything else in the Sprint because support tickets are spiking. The Developers agree and quietly change the Sprint's plan without looping in the Product Owner. What is the problem with this outcome?
Select an answer to reveal the explanation.
Short Explanation
Support tickets spiking is real signal, and that's exactly why it should land on the Product Owner's desk, not slip in through a side door to the Developers. Self-management covers how the Developers do the work, not who gets to decide what's most valuable to work on next.
Full Explanation
Self-management gives the Developers control over how work gets done within a Sprint, but it does not transfer accountability for the Product Backlog's content and order — that stays with the Product Owner. A support lead going straight to the Developers, however urgent the ticket volume feels, routes a prioritization decision around the one person accountable for making it, and the Product Backlog now reflects an ad hoc agreement rather than a considered ordering. This matters more, not less, under pressure: an overheating battery might genuinely deserve to jump the queue, but the Product Owner needs to see it against everything else in flight — a certification deadline, a retail commitment, other open items — to make that call responsibly. The fix isn't red tape; the Guide doesn't prescribe a change-control process, so inventing a ticket system misses the point too. The Scrum Master's role is to help stakeholders understand how to engage the Product Owner, not to approve priorities. A useful check: does the current top of the Sprint's work trace back to a decision the Product Owner is aware of and stands behind, or did it arrive through a side channel?