A council aide loudly demands a vanity map theme at the top of a transit-app Product Backlog. Developers have also surfaced a high-risk fare-calculation dependency that could stall several upcoming items. How should the Product Owner order the work?
Select an answer to reveal the explanation.
Short Explanation
The person with the loudest voice is not a value model. If a hidden fare-calc snag can stall half the map, that risk belongs near the top whether or not it photographs well. The Product Owner stacks work by value, risk, dependencies, and learning—not by who cornered whom in the hallway.
Full Explanation
Product Backlog order should reflect value, risk, dependencies, and the value of learning—not stakeholder volume. When a council aide loudly demands a vanity map theme atop a transit-app Product Backlog while Developers surface a high-risk fare-calculation dependency that could stall several upcoming items, the Product Owner should order using those factors rather than whoever shouted last. Putting the aide’s theme first to protect the political relationship regardless of value or risk subordinates empiricism to vanity. Alphabetizing the Product Backlog so ordering cannot be accused of bias abandons value-based ordering entirely. Rotating the top item each Sprint among departments keeps the peace while ignoring opportunity cost and technical risk. Exam caveat: political visibility items may still appear on the backlog, but they compete on value, risk, and learning like everything else—they do not automatically win. Operational check: make the fare-calculation dependency an explicit Product Backlog item, place it where it unblocks forecastable value, document why the vanity theme is ordered lower, and inspect at Sprint Review whether transit outcomes and risk exposure justify the sequence.