The transit-app Scrum Team waits a month in a shared-services user-experience queue before any fare-flow experiment can be designed. What should the Product Owner argue?
Select an answer to reveal the explanation.
Short Explanation
A month in the UX waiting room is a month the fare app cannot learn. Scarce skills parked in a shared queue look efficient and feel like a traffic jam. Embed the skill in the Scrum Team when the product cannot deliver without it.
Full Explanation
Shared-service queues for scarce skills such as user experience create delay that damages Time-to-Market and Ability to Innovate. When the transit-app Scrum Team waits a month in a shared UX queue before any fare-flow experiment can be designed, learning with riders stalls and Unrealized Value sits idle. When that skill is critical to fare-app value, the Product Owner should argue for embedding user-experience skill in the Scrum Team rather than optimizing specialist utilization in a central pool. Product Owner-written interface specs or annual redesign projects do not restore rapid inspection with riders.
Keeping UX as a shared queue so specialists stay fully utilized fails by prioritizing utilization over flow of citizen value. Having the Product Owner write all interface specifications to skip the queue fails because writing specs is not a substitute for UX skill inside the team. Waiting until a yearly redesign is funded fails by batching learning into a slow project instead of Sprint-level experiments.
Exam caveat: Embed critical UX skill in the Scrum Team when shared queues structurally delay value. Operational check: Staff UX into the transit-app team for fare-flow work and compare experiment lead time to the prior one-month shared-queue wait.