A library branch manager keeps a spreadsheet of "the real work" and tells Developers to follow it instead of the Product Backlog. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
Two maps of the same city is how people drive into the river. A shadow spreadsheet is a second product pretending not to be one. The Product Owner kills the duplicate source of truth so the team has one ordered list.
Full Explanation
A Product Backlog is the single source of work for a product. When a library branch manager keeps a spreadsheet of “the real work” and tells Developers to follow it instead of the Product Backlog, that shadow list destroys transparency and lets unofficial order override value-based order for patrons and staff. The Product Owner must eliminate the shadow backlog so one Product Backlog remains the source of truth. Maintaining both lists and reconciling them at year-end close keeps the dual-source problem alive for months of civic delivery. Asking the Scrum Master to copy spreadsheet rows into the tool after each Daily Scrum without ending the dual-source pattern only legitimizes the shadow process. Making the spreadsheet the Product Backlog for that branch while keeping a separate citywide backlog invents a fake product boundary to avoid collapsing competing lists. Exam caveat: branch-specific needs can become Product Backlog items, but they must compete in one ordered list under Product Owner accountability—not as a parallel command channel. Operational check: retire the spreadsheet as an ordering authority, migrate legitimate branch needs onto the single backlog, communicate the change to Developers and the manager, and inspect at Sprint Review that no side list is driving Sprint selection.