Using Sprint Cancellations to Change Scope

The product owner can cancel a sprint before its time box has expired, but taking this drastic step is disruptive. If the sprint goal becomes obsolete it could make sense to terminate the Sprint. But a sprint is short enough that it very rarely makes sense to prematurely end a sprint.

Sometimes the product owner will cancel a sprint to impose their will on the Scrum team, or do so as a kind of negotiation tactic. Yes, the product owner does have the authority to cancel a sprint; however, that decision is usually made in consultation with the Scrum master and the development team, because it’s such a dramatic and destructive occurrence. If the product owner uses it as a tactic to negotiate scope or schedule, there are likely greater dysfunctions on the team that the Scrum master can jump in and help with.

That said, never canceling may also be an anti-pattern. If you surveyed a lot of Scrum teams, you’d find that many have never canceled a sprint. That’s interesting because, at some point, it’s likely that it didn’t make sense to continue developing something for their product (especially if changing circumstances made the sprint goal unachievable), so canceling would actually have been the best course of action.

Just like unnecessarily canceling a sprint, continuing a sprint that will never deliver value can also waste time. And so, when circumstances change, even if you’ve never canceled a sprint before, perhaps it’s worth discussing.

That said, canceling a sprint should be an anomaly. Be very cautious about using this nuclear option. The major disruption that it causes is rarely worth it.