Four parks-reservation teams plan to integrate only at the end of the quarter so they can move faster during Sprints. What should the Product Owner require?
Select an answer to reveal the explanation.
Short Explanation
Integrating once a quarter is building four gazebos in different yards and hoping they form a park in December. The broken bolts show up too late. Want one usable parks product every Sprint.
Full Explanation
Even when multiple teams work on one product, the Increment must be integrated and Done at least by the end of each Sprint. When four parks-reservation teams plan to integrate only at quarter's end so they can move faster during Sprints, the Product Owner should require a Done, integrated Increment of the parks product at least every Sprint. Deferred integration hides defects, dependency thrash, and undone work until a late big bang and removes empiricism from the civic product.
End-of-quarter integration so each team can maximize its own story count optimizes local output over product usability. A separate integration team that holds quality until the quarterly demo recreates a hardening silo. Separate release branches that merge only when marketing names a season couple integration to publicity, not to Done.
Parks reservation users meet one system; quarterly integration bets their experience on a late discovery of broken seams.
Exam caveat: PSPO II multi-team Increments are integrated each Sprint; quarterly integration is a standing fail.
Operational check: change the Definition of Done to require cross-team integration of parks reservation every Sprint, and stop counting team-local story completion as a product Increment.