The app team's next Increment depends on a firmware API that the firmware team has not yet finished. Both teams share one Product Backlog. What is the most empirical way for the Scrum Teams to manage this cross-team dependency?
Select an answer to reveal the explanation.
Short Explanation
Dependencies don't disappear if you ignore them, but they also don't need a master plan drawn up months in advance. Put the dependency where both teams can see it, check on it together often, and let each Sprint's real progress tell you what to adjust next.
Full Explanation
The mechanism is treating a cross-team dependency through the same transparency-inspection-adaptation cycle Scrum already uses, rather than through upfront sequencing. A shared Product Backlog makes the dependency visible as an ordered item, and a joint look at real progress, commonly surfaced around Sprint Review, lets both teams adapt their own plans based on actual status instead of a plan made in advance. Guessing at the API's shape and reworking later, the response this question is built around avoiding, produces wasted work and a false sense of progress, which is the opposite of transparency. A master schedule from an outside program manager reintroduces upfront, centralized planning that the Scrum Teams themselves should own and adapt, and it isn't a role the Guide describes. Pausing the app team's Sprints entirely overreacts, since there is very likely other backlog-ordered work the app team can pull while the dependency resolves. Caveat: visibility alone doesn't resolve a dependency; someone still has to act on what's seen. Operational check: add an explicit note or item on the shared backlog naming the dependency and revisit its status at least every Sprint.