As a parks recreation-booking product scales, the city creates a requirements bureau that writes and sequences backlog items, leaving the Product Owner to communicate them to the teams. What should the candidate identify?
Select an answer to reveal the explanation.
Short Explanation
A requirements bureau above the Product Owner is a waterfall intake desk with a new badge. The Product Owner is supposed to own order and value on the parks booking product, not read someone else's list into the teams. Scaling should not steal that accountability.
Full Explanation
Scaling structures must preserve the Product Owner's accountability for maximizing value and for the Product Backlog. As a parks recreation-booking product scales, when the city creates a requirements bureau that writes and sequences backlog items and leaves the Product Owner to communicate them to the teams, the candidate should identify that the bureau undermines Product Owner accountability for the Product Backlog and should not sit above that role. Scaling should not steal ordering and value decisions from the Product Owner.
Calling the bureau a healthy scaling pattern because it standardizes requirements intake mislabels a waterfall hierarchy as agility. Having the Product Owner join the bureau as a scribe and stop ordering the backlog completes the demotion of the role. Having the Scrum Master report to the bureau so facilitation stays aligned to specifications subordinates Scrum facilitation to a specification factory.
Exam caveat: PSPO II scaling must not place a requirements bureau above the Product Owner; collaboration with analysts is fine, replacement of backlog accountability is not.
Operational check: dissolve or demote the bureau's sequencing authority, restore Product Backlog order to the Product Owner, and keep analysts as helpers who refine items the Product Owner still orders toward the parks Product Goal.