Agency directors keep sending the transit-app Product Owner new rider-feature lists and assume each list will ship. How should the Product Owner set expectations?
Select an answer to reveal the explanation.
Short Explanation
Think of a lunch counter with one cook: the menu can hear every craving, but not every plate gets made. A healthy Product Owner says that out loud. Ordering is choosing, and choosing means some ideas wait or die.
Full Explanation
Agency directors often treat submitted rider-feature lists for a transit app as implicit commitments. Advanced Product Ownership requires transparent expectation-setting that Product Backlog order is a value decision, not a queue of promises. The Product Owner should make it clear that ordering for value means some stakeholder requests will wait or never be done because opportunity cost and the Product Goal make them lower value. That honesty protects forecast integrity and civic trust more than polite overcommitment.
Promising every director a Sprint of their own fails because political fairness replaces Product Backlog order and empiricism with time-sliced politics. Converting every request into a committed annual roadmap item fails by creating false certainty and turning declines into deferred theater. Hiding declined requests from the Product Backlog fails because transparency is a Scrum Value; concealing work destroys stakeholder trust and inspection.
Exam caveat: A submitted request is not a commitment; transparent ordering includes the hard no. Operational check: Publish a simple intake and order view for the transit app that shows requested, ordered, waiting, and declined items with a one-line value rationale so directors stop equating submission with shipment.