After slow delivery on a public-health case-management product, the CIO wants to add three Scrum Teams immediately. Product boundaries with clinic records and lab reporting are still unclear. What should the Product Owner seek first?
Select an answer to reveal the explanation.
Short Explanation
Adding teams to a blurry product is hiring more cooks before deciding whether this is a diner or a catering hall. That just scales the confusion. Right-size the case-management product and the work first; headcount later.
Full Explanation
Scaling team count without a clear product boundary multiplies dependencies, competing goals, and undone integration. After slow delivery on a public-health case-management product, when the CIO wants to add three Scrum Teams immediately while product boundaries with clinic records and lab reporting remain unclear, the Product Owner should seek to clarify the product boundary and value focus before adding teams that would scale confusion. Fake scale looks busy and delivers less for clinics.
Adding the three teams now and sorting product boundaries during PI Planning scales the blur first and hopes ceremony fixes it later. Splitting the unclear work across six component teams so more people stay busy worsens integration and ownership. Creating a requirements bureau to feed all new teams from a single specification stack parks a waterfall intake above the Product Owner.
Exam caveat: PSPO II scale follows clear product boundaries and value focus; headcount is not the first lever after slow delivery.
Operational check: define what the case-management product is and is not relative to clinic records and lab reporting, name the Product Goal, then decide whether more teams would actually increase value.