A home-robot company now runs three Scrum Teams — app, firmware, and cloud — pulling from one Product Backlog. At the Sprint Review, the firmware team's Increment only becomes meaningful once it's paired with the app team's companion-app update. What should the Sprint Review do in this case?

With multiple Scrum Teams working from one Product Backlog, the Increment is still meant to represent a coherent, usable step toward the Product Goal, so when Increments are interdependent, the Sprint Review needs to surface that combined state rather than pretend each team's slice stands alone. The Guide's purpose for the event — inspecting the outcome of the Sprint and determining future adaptations — only works if what's inspected reflects reality. Fully separate reviews that never connect the pieces would hide the actual integration risk from stakeholders, which defeats transparency. Skipping the firmware team's Review because its output isn't independently valuable ignores that the Review is a required event for every Scrum Team every Sprint, and 'not independently shippable' is itself useful information to surface, not a reason to withhold it. Postponing the Review until every team's work is independently shippable abandons the timebox — the Sprint ends on schedule regardless of dependency status, and inspection has to happen against whatever exists at that point, imperfect integration included. A concrete check: when teams are interdependent, look for whether the organization has arranged a shared review of the composite product, even if each team also does its own team-level inspection first.