A transit Product Backlog still carries items for a fare-pilot Product Goal that the city retired last quarter. Stakeholders say to leave them just in case. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A menu still listing last year's specials is how kitchens cook the wrong food. If the fare pilot is dead, those items are clutter, not options. The Product Owner prunes so the list still tells the truth about where the product is going.
Full Explanation
The Product Goal is the commitment for the Product Backlog; items that cannot serve it should be removed or explicitly reconsidered. When a transit Product Backlog still carries items for a fare-pilot Product Goal the city retired last quarter and stakeholders say to leave them just in case, the Product Owner should remove items that no longer serve the current Product Goal so the backlog stays honest for riders and operators. Keeping stale items at the bottom forever reduces transparency and invites accidental selection of obsolete work during Sprint Planning. Converting them into a second Product Goal so the old work remains a commitment dilutes focus and recreates parallel destinations. Moving them onto the Sprint Backlog so Developers can mark them Done without building them corrupts Done and the Increment. Exam caveat: some retired work may seed a new Goal later, but then it should be reframed under that Goal—not left as zombie commitments on a living civic backlog. Operational check: purge or archive fare-pilot items that cannot serve the current Goal, publish the cleaned backlog, confirm stakeholders understand the retirement, and inspect that Sprint forecasts no longer drift toward dead pilot scope.