In a council briefing on the building-permit portal, an official asks the Product Owner to 'commit the team' to a six-month forecast. How should the Product Owner respond?
Select an answer to reveal the explanation.
Short Explanation
Asking the Product Owner to 'commit the team' is like asking the restaurant host to promise how many steaks the kitchen can fire tonight. The cooks know the grill. The Product Owner orders the menu and the outcome; Developers forecast capacity.
Full Explanation
In a council briefing, asking the Product Owner to commit the team to a six-month building-permit forecast confuses roles. Developers forecast how much they can deliver based on capacity and empiricism; the Product Owner owns Product Backlog order and product goals, not a personal promise of Developer capacity. Signing the forecast as a team commitment with a penalty clause if Developers miss the date turns a hypothesis into a contract and undermines transparency. Converting the forecast into one Sprint Goal that spans all remaining Sprints misuses Sprint Goals, which describe a single Sprint's coherent purpose. Transferring forecast ownership to the Scrum Master so the Product Owner can stay focused on stakeholders abdicates Product Owner accountability for ordering and product outlook. Exam caveat: know who owns what—Product Owner for value order and goals; Developers for delivery forecast of their work. Operational check: present backlog order and Product Goal clearly, invite Developers to speak to capacity-based ranges, and refuse to personalize a six-month capacity guarantee as the Product Owner's signature. Role clarity in council briefings prevents false capacity promises: Developers speak to delivery ranges; the Product Owner speaks to order and goals. Refuse signature theater that turns a six-month hypothesis into a personal commitment with penalties.