A retail buyer asks the Product Owner to confirm, in writing, that a specific list of companion-app features will be complete by a fixed date six months out. The Product Owner instead explains this as a forecast based on recent Sprints. What is the Product Owner correctly reflecting about Scrum?
Select an answer to reveal the explanation.
Short Explanation
A forecast isn't a promise carved in stone, it's the team's best guess today, built from what they've actually delivered so far. As more real Sprints happen, that guess gets sharper or it changes, and that's not a broken commitment, it's the plan working as intended.
Full Explanation
The mechanism is that Scrum treats the future as uncertain and handles it through inspection and adaptation rather than upfront guarantees: a Product Owner can offer a forecast built from what Sprints have actually produced, but that forecast is expected to be revised as new information, such as a certification delay, a supplier issue, or a customer signal, comes in. Presenting a six-month scope-and-date pair as fixed would misrepresent how empirical work behaves. The Scrum Master approval distractor invents a gatekeeping role the Guide doesn't assign; the Scrum Master supports the Product Owner but doesn't authorize external communications. The pre-existing six-month Sprint Backlog distractor is impossible by definition, since a Sprint Backlog is created for one Sprint at a time by the Developers. The Developer vote distractor misassigns Product Backlog and stakeholder communication, which sits with the Product Owner. Caveat: a forecast should still be honest and grounded, not a shrug, it needs real data behind it. Operational check: refresh the forecast at every Sprint Review using the most recent completed work, and tell the buyer explicitly that the number can move.