A home-robot company's Product Owner considers cancelling a Sprint after a competitor unexpectedly launches a similar product, but the Sprint Goal is still partly reachable. According to the Scrum Guide, how should the Product Owner treat the decision to cancel?
Select an answer to reveal the explanation.
Short Explanation
Cancelling a Sprint is a big lever, not a light switch — you don't flip it just because the market moved. Because it costs the team real time and morale, the Guide treats it as rare, worth reaching for only when the Sprint Goal is genuinely obsolete, not merely inconvenient. If the goal can still be adapted instead of scrapped, that's usually the better move.
Full Explanation
The Scrum Guide notes that Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning, and are often traumatic to the Scrum Team, so cancellations are rare. Here the Sprint Goal is still partly reachable, which is the key signal — the Product Owner's job is to weigh whether adapting the plan within the Sprint serves better than scrapping it outright, and the Guide reserves cancellation for when the Sprint Goal becomes obsolete, not merely when circumstances change. Treating cancellation as routine misreads that rarity and would erode the stability a Sprint's timebox is meant to provide the team. The Scrum Master has no authority to cancel a Sprint regardless of how well impediments are documented — only the Product Owner holds that authority. A Developer vote has no standing here either; cancellation is not a self-management matter for the Developers, since it concerns whether the Sprint's purpose still holds, which is a Product Owner accountability. A concrete check: before cancelling, ask whether the current Sprint Goal can be reinterpreted or the Sprint Backlog renegotiated with the Developers to still deliver something valuable — cancellation is the last resort, not the first response to new information.