The parks Product Owner maps friends-of-the-park groups, field supervisors, and the budget office by interest and influence. The highest-influence supervisor then demands the right to reorder the Product Backlog after every map review. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A stakeholder map is a seating chart, not a transfer of the gavel. Knowing who cares and who can block you is smart; letting the loudest square on the map grab the backlog is not. The Product Owner still orders the work.
Full Explanation
Stakeholder maps inform collaboration; they do not transfer Product Backlog ordering rights. When the parks Product Owner maps friends-of-the-park groups, field supervisors, and the budget office by interest and influence, and the highest-influence supervisor then demands the right to reorder the backlog after every map review, the Product Owner should use the map to plan engagement while remaining the single person who orders the Product Backlog. Handing ordering to the highest-influence cell so politics stay calm abandons Product Owner accountability. Averaging stakeholder votes weighted by influence scores to set official order replaces value judgment with politics math. Hiding the map so no stakeholder can claim a right to order work reduces useful transparency about who to involve. Exam caveat: influence identifies who must be heard and aligned; hearing is not co-ownership of order under Scrum. Operational check: keep ordering authority explicit, use the map to invite the right voices into refinement and Review, document decisions against the Product Goal, and refuse post-map automatic reorder privileges for supervisors. Keep civic stakeholders focused on inspectable outcomes for residents and operators rather than inbox politics or vanity metrics.