With four feature teams now working from one Product Backlog toward a fixed retail launch window, a hardware-parts delay threatens two other teams' planned work. What is the most empirically grounded response?
Select an answer to reveal the explanation.
Short Explanation
A delay that only one team knows about is a delay that's about to blindside two more teams. The honest move is to put the real impact on the table for everyone sharing that backlog, so each team can adjust its own plan based on what's actually true right now.
Full Explanation
The mechanism is again transparency feeding adaptation across teams that share one Product Backlog: real, current facts about the delay need to be visible to everyone affected so each team can replan based on what's actually happening rather than on the original assumption that no longer holds. Isolated adjustment without informing others recreates exactly the lack of transparency that makes coordinated risk management fail, since two other teams keep planning around a fact that's already changed. Waiting for full resolution before reacting at all wastes the time between now and resolution, when partial replanning could already begin with what is known. Dumping all the affected work onto a single team ignores that the Developers on each team are best positioned to judge their own capacity and self-manage their response, and it manufactures a new bottleneck instead of resolving the original one. Caveat: transparency about a risk isn't the same as having a fix for it; sharing the facts is the first step, not the whole response. Operational check: raise the delay's known impact at the next cross-team Sprint Review or an equivalent syncing point so every affected team can react from the same current information.