Outsourcing contracts split transit-app work into a vendor interface team and a city backend team that cannot share one Sprint Goal or Definition of Done. What should the Product Owner seek?
Select an answer to reveal the explanation.
Short Explanation
A contract can build a wall faster than any org chart. If the vendor UI shop and the city backend cannot share a Sprint Goal, riders will keep waiting on half-done fare screens. Reshape the contracting model so one Scrum Team can actually finish a transit Increment.
Full Explanation
Commercial boundaries often become team boundaries, even when that design cannot produce a Done Increment of citizen value. When outsourcing contracts split transit-app work into a vendor interface team and a city backend team that cannot share one Sprint Goal or Definition of Done, riders keep waiting on half-finished fare screens. An advanced Product Owner treats contracting as organizational design and seeks models—capacity, outcomes, or integrated teams—compatible with one Scrum Team that can produce a single Done transit Increment. Scheduling the wall more carefully does not remove the wall.
Stricter statement-of-work gates so the vendor never collaborates fail by hardening the handoff. Two Product Owners, one per contract, fail by matching the vendor wall with split accountability. A program schedule that sequences vendor handoffs fails by coordinating the dependency instead of changing the contracts.
Exam caveat: Contracts must enable one Scrum Team and one Done Increment, not invent permanent handoff walls. Operational check: Renegotiate transit-app contracting so vendor and city engineers share Sprint Goal, Definition of Done, and release of a single Increment rather than sequenced UI-then-backend packets.