An enterprise architecture review board must approve every Increment of the 311 request product before release, often adding weeks of wait time. What should the Product Owner seek?
Select an answer to reveal the explanation.
Short Explanation
A bouncer on every Sprint door turns “potentially releasable” into “please take a number.” You still want standards — just not a marble staircase between Done and citizens. Light guardrails beat a standing committee that eats Time-to-Market.
Full Explanation
Centralized architecture gates on every Increment of a 311 request product lengthen Time-to-Market and weaken empiricism because stakeholders cannot inspect value in production-like conditions. Architecture constraints can be expressed as lighter guardrails, shared Definition of Done elements, or embedded skills rather than a sequential approval board that adds weeks of wait. The Product Owner should seek to replace the heavy gate with lighter guardrails that protect standards without stopping flow, because delayed release is delayed learning about citizen request outcomes.
Accepting the gate and pausing Sprint Reviews until architecture signs fails because it freezes inspection waiting for a bureaucracy. Expanding the board’s checklist fails by documenting quality while further slowing flow. Bypassing production and demonstrating only slideware fails because slideware is not a Done Increment residents can use.
Exam caveat: Standards can be guardrails inside Done; they need not be a multi-week board on every Increment. Operational check: Negotiate with enterprise architecture a guardrail checklist embedded in the 311 Definition of Done, plus spot audits, so low-risk Done Increments are not held for weeks.