HR assigns Developers from a shared resource pool to the parks booking Scrum Team on a weekly rotation to maximize utilization. What should the Product Owner argue for?
Select an answer to reveal the explanation.
Short Explanation
A band that swaps musicians every Friday never learns the songs. Products need a stable crew who remember the customers and the code. A utilization pool is great for filling chairs, terrible for finishing a Product Goal.
Full Explanation
Constant rotation from a shared HR resource pool optimizes specialist utilization at the expense of focus, knowledge, and forecastable delivery for parks booking. Stable Scrum Teams develop shared understanding of the Product Goal, stakeholders, and technical risks, which improves value delivery. The Product Owner should argue for a stable Scrum Team that can hold product knowledge and deliver consistently rather than accepting a weekly rotation model that treats Developers as interchangeable hours. Rotating the Product Owner or outsourcing the team would worsen product accountability.
Keeping weekly rotation so more specialists touch the product fails because utilization and exposure are not substitutes for continuity. Rotating the Product Owner weekly fails by destroying ordering accountability to match a bad staffing model. Replacing the Scrum Team with on-demand vendors fails when parks needs durable product ownership and knowledge retention.
Exam caveat: Stability of the Scrum Team is an org-design prerequisite for empiricism and product knowledge. Operational check: Ask HR and leadership to stop weekly rotations onto parks booking, name a durable team roster for at least several Sprints, and measure forecast reliability before versus after stability.