Mid-Sprint, middle managers pull Developers off the transit-app team for “higher-priority projects,” wrecking the Sprint Goal and the release forecast. What should the Product Owner escalate?
Select an answer to reveal the explanation.
Short Explanation
You cannot forecast a bus route if the driver keeps getting pulled to drive a parade. Mid-Sprint yanking is an org-design problem, not a motivation problem. Escalate the WIP and protect the team’s focus, or every forecast is fiction.
Full Explanation
Structures that reassign people mid-Sprint destroy Focus, invalidate forecasts, and treat the Sprint Goal as optional. When middle managers pull Developers off the transit-app team for “higher-priority projects,” the Product Owner should escalate the structural WIP and focus problem so people are not yanked mid-Sprint. Civic products need reliable empiricism, which requires protected focus for the Sprint and honest forecasts for riders and sponsors. Heroic overtime or constantly rewriting the Sprint Goal hides the structural problem rather than fixing it.
Accepting the pulls and re-baselining the Sprint Goal every time fails because it normalizes instability and makes every release forecast fiction. Asking Developers to work nights to finish both the Sprint Goal and side projects fails by substituting burnout for organizational design. Converting the Sprint into a board of management interrupts fails by visualizing dysfunction as if it were a healthy operating model.
Exam caveat: Mid-Sprint reassignment is an organizational impediment to Focus and forecasting, not a motivation issue. Operational check: Escalate to leadership a policy that transit-app team membership is stable for the Sprint, with portfolio trade-offs made between Sprints—not via hallway pulls.