Two feature teams building the same home-robot product — one for the companion app, one for the onboard firmware — each keep their own Definition of Done, and their separately "Done" work frequently fails to function correctly once combined, so what should the teams do?
Select an answer to reveal the explanation.
Short Explanation
Picture two contractors each declaring their part of a house "finished" by their own separate rulebook — the plumbing passes the plumber's checklist and the wiring passes the electrician's, but nobody checked whether they fit together in the same wall. When multiple teams build one product, they need one shared Definition of Done so a combined Increment that everyone calls Done is actually usable as a whole.
Full Explanation
When more than one team contributes to a single product, a Definition of Done that only covers each team's own slice creates a false sense of completeness: each team's work can pass its own bar while the combined system still fails, because integration between components was never part of anyone's standard. The fix is a shared Definition of Done that both teams use, which at minimum must include everything needed for the combined Increment to be usable and releasable together — including cross-component integration checks. This does not mean every team does identical work; it means the bar for calling something Done reflects what the whole product needs, not just one component in isolation. Assigning integration to a single team as an afterthought treats the symptom rather than the cause, and having the Product Owner personally test everything conflates the Product Owner's accountability for value with a quality-assurance role that belongs to the Developers. A concrete check the teams can run each Sprint is to ask whether an Increment that passes both teams' individual criteria has actually been exercised together end to end — if that step doesn't exist in the shared Definition of Done, the standard is still incomplete.