Public-works inspection requests currently live in three department ticket queues plus a shared spreadsheet. Directors each pull Developers toward their own list. What should the Product Owner do?

Scrum uses one Product Backlog per product, ordered by the Product Owner. When public-works inspection requests live in three department ticket queues plus a shared spreadsheet and directors each pull Developers toward their own list, the Product Owner must consolidate one ordered Product Backlog for the inspection product and remain accountable for that order. Multiple departmental queues destroy transparency and invite local optimization at the expense of overall civic value. Keeping a separate backlog per department so each director feels equally served preserves the food fight. Asking the Scrum Master to merge tickets after each Sprint Review as a facilitation courtesy leaves the dual-source problem in place and misplaces ordering accountability. Turning every department queue into its own product with a separate Product Goal avoids the real ordering decision by inventing fake product boundaries. Exam caveat: portfolio-level capacity sharing across true products can be explicit; silently parallel queues for one inspection product are not portfolio management. Operational check: migrate all inspection work into one visible Product Backlog, publish the order and Product Goal, stop accepting side pulls, and inspect at Sprint Review whether directors can still see how trade-offs were made.