On a transit real-time-arrivals product, Developers keep pulling refactor tickets from a private tech queue that never appears on the Product Backlog, while rider-facing reliability work stalls. What should the Product Owner do?
Select an answer to reveal the explanation.
Short Explanation
A hidden tech queue is a second kitchen nobody can see from the dining room. Refactors that make buses show up on time are product work, not a side hobby. Put that work on the one backlog and order it for the rider value it unlocks—not as an unmanaged stash.
Full Explanation
Enabling technical work that unlocks product value belongs on the Product Backlog, ordered transparently. When Developers on a transit real-time-arrivals product keep pulling refactor tickets from a private tech queue while rider-facing reliability work stalls, the Product Owner should collaborate with Developers to surface that enabling work and order it for the value and risk reduction it unlocks. Banning all technical work until every rider story is finished ignores dependencies that make reliability impossible for riders. Letting Developers keep a private tech backlog so Product Backlog order stays “business-only” recreates a shadow source of truth and hides opportunity cost. Handing the tech queue to a platform manager who can order it without the Product Owner fragments accountability for the transit product. Exam caveat: not every refactor is valuable; order technical work by outcomes and risk, not by developer preference alone. Operational check: migrate high-value refactors onto the Product Backlog, pair each with the reliability or delivery outcome it enables, stop private pulls, and inspect whether rider-facing reliability measures improve after those Increments meet the Definition of Done.