Company leadership asks the Product Owner for a single, guaranteed unit-count the home robot will sell by the retail launch date so they can commit to a supplier contract. The Product Owner is uneasy about giving a single hard number. What is the soundest Scrum-based reasoning for that unease?
Select an answer to reveal the explanation.
Short Explanation
A forecast with no room for things shifting isn't really a forecast anymore, it's a guess wearing a suit. The honest version comes with some acknowledgment that things could change, because that's what a number built from partial evidence actually is.
Full Explanation
The mechanism is that a forecast, by its nature, reflects a current best estimate built from available evidence, and evidence changes as more Sprints complete and more of the product and market reality becomes known; presenting it as an unconditional guarantee misrepresents that. Treating supplier contracts as outside the Product Owner's accountability, so any number is non-binding, dodges the real question rather than addressing why a single hard number is unsound in the first place. Reassigning the number's accountability to the Developers misattributes it; the Developers forecast Sprint-level work, but market and value forecasting to outside stakeholders sits with the Product Owner. Suggesting the Scrum Master handle supplier negotiation invents a role the Guide never assigns; supplier contracts sit outside the Scrum Team's accountabilities altogether, but that's not the reason the number itself is a bad idea. Caveat: this doesn't mean giving leadership nothing, it means giving a defensible estimate along with its uncertainty rather than false precision. Operational check: attach the forecast's underlying assumptions and a revision cadence so leadership knows exactly when and why the number might change.