Two Scrum Teams share one city permitting product. One team treats accessibility and records-retention checks as Done; the other ships coded screens without them. What should the Product Owner support?
Select an answer to reveal the explanation.
Short Explanation
Two Done bars on one permit product is like two kitchens sharing a restaurant with different food-safety rules. Residents meet one product, not two teams. Back one quality bar so Done means the same thing.
Full Explanation
When multiple teams work on one product, their Increments must integrate to a single usable product, which requires a shared Definition of Done at least as strict as the product needs. If two Scrum Teams share one city permitting product and only one treats accessibility and records-retention checks as Done, residents still meet one product. The Product Owner should support one shared Definition of Done that holds every Increment to the same product-quality bar.
Separate Done definitions so each team can optimize its own velocity create an undone permitting product even when each team finishes locally. A program increment checklist owned by a PMO instead of the Scrum Teams moves quality outside Sprint-level Done. Deferring the stricter checks until a citywide audit week each quarter hides undone work for most of the quarter.
Accessibility and retention on permits are resident rights and legal duties, not optional team preferences for velocity.
Exam caveat: PSPO II multi-team products need a shared Done; team-local weaker Done is a scaling anti-pattern.
Operational check: publish one permits Definition of Done including accessibility and retention, require both teams to meet it every Sprint, and stop calling locally coded screens Done when those checks are missing.