A vendor contract for a city services platform ties payment to a single big-bang go-live. What should the Product Owner advocate?
Select an answer to reveal the explanation.
Short Explanation
Big-bang go-live is a cliff, and cities fall off cliffs. Negotiate milestones that pay for real, releasable slices and still honor the contract's intent. Hide-the-Increment tricks just keep the cliff on the calendar.
Full Explanation
Contracts that tie payment for a city services platform to a single big-bang go-live can still be steered toward incremental value. The Product Owner should advocate releasable forecasts and negotiated milestones that satisfy procurement intent without requiring one fantasy go-live as the only inspection point. Hiding incremental Increments so the vendor is not paid early preserves the big-bang bet and withholds learning the city needs before full cutover. Canceling Scrum until the contract is fully delivered because Increment reviews would supposedly violate procurement misreads both Scrum and most modern procurement flexibilities; Reviews inspect value, they do not automatically breach the agreement. Treating the contract date as the Product Goal and freezing scope until go-live replaces citizen outcomes with a calendar constraint and blocks adaptation when evidence arrives. Exam caveat: PSPO II treats contracts as negotiable constraints around value delivery, not as substitutes for Product Goals or empiricism. Operational check: propose milestone language tied to Done Increments stakeholders can inspect, keep the Product Goal outcome-focused, and refuse any forecast that depends on a single unvalidated big-bang release.