As the home-robot product scales to an app Scrum Team and a firmware Scrum Team, each team defines its own separate Definition of Done for its component, and integrated releases keep failing because "done" firmware sometimes breaks against "done" app builds. What does the 2020 Scrum Guide indicate should happen?
Select an answer to reveal the explanation.
Short Explanation
Two teams, two "Done" checklists, and neither one guarantees the pieces actually fit together — that's the gap here. When multiple teams build one product, they need one shared Definition of Done their combined Increment has to clear, not two definitions that never talk to each other.
Full Explanation
The Scrum Guide is clear that when multiple Scrum Teams work together on one product, they must mutually define and comply with the same Definition of Done, because the Increment is a step toward one Product Goal and has to be usable as a whole, not as disconnected pieces each satisfying a private standard. Letting each team keep a separate Definition of Done is exactly the setup that produced the integration failures described — component-level "done" says nothing about whether the combined product actually works. Relying on the Product Owner to manually test every integration substitutes a person for a process and doesn't scale, and it also isn't the Product Owner's accountability — Done is a quality standard the Developers uphold together. Delaying integration until the very end reintroduces the late-integration risk Scrum's iterative approach is specifically designed to avoid, trading early, cheap feedback for a late, expensive surprise. A concrete check: have both teams write down one shared Definition of Done document and verify every Increment, from either team, is validated against that single standard before being called Done.