Mid-Sprint, a building-inspections manager adds an item to the Product Backlog and expects the Sprint Backlog to change automatically so Developers drop current work. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Adding a sticky note to the fridge does not magically rewrite tonight's dinner. The Product Backlog can take new work; the Sprint Backlog is the team's plan for this Sprint. If something truly must interrupt, that is a conversation about the Sprint Goal—not an automatic swap.
Full Explanation
The Product Owner is accountable for the Product Backlog; Developers are accountable for the Sprint Backlog as their plan toward the Sprint Goal. When a building-inspections manager adds an item mid-Sprint and expects the Sprint Backlog to change automatically so Developers drop current work, the Product Owner must clarify that Product Backlog updates do not by themselves rewrite an active Sprint. Any warranted mid-Sprint disruption is a collaborative decision that protects or renegotiates the Sprint Goal. Forcing the new item into the Sprint Backlog because the Product Owner owns every artifact confuses Product Backlog accountability with Sprint Backlog ownership. Telling the manager the Product Backlog is frozen until the next fiscal year is an extreme that blocks legitimate upcoming order changes. Cancelling the Sprint automatically whenever the Product Backlog gains an item treats every insertion as catastrophic and ignores empiricism. Exam caveat: urgent inspection work can enter the Sprint if the Product Owner and Developers agree and adapt the Sprint Goal—but that is collaboration, not automatic injection. Operational check: place the new item on the Product Backlog in transparent order, discuss impact on the current Sprint Goal with Developers, change the Sprint only by agreement if needed, and explain the distinction to the inspections manager with the next civic Increment in view.