Although a cancelled Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting. Teams should immediately re-start after cancelling a Sprint. One team I heard of was doing two week Sprints, cancelled due to a major tool problem, and then waited three months for the vendor to fix the problem before going back to Sprinting. Instead, they should have used their creative problem-solving skills to find a way to continue delivering value and restarted their Sprints immediately.

The Scrum Guide puts Sprint cancellation under the authority of the Product Owner:

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

It is important to note that older descriptions of Scrum will sometimes mention that the ScrumMaster or the Development Team can also cancel a Sprint. This is no longer part of the core definition of Scrum.

Cancelled Sprint Emotions

A cancelled Sprint can sometimes be emotionally challenging for a Scrum Team. There are three reasons for this difficulty:

Cancelling a Sprint, particularly later on in the timebox means there’s a lot of work already in progress (and possibly done). The psychology of sunk costs comes into play: we’ve invested some much in the Sprint so far, let’s just keep going to see if we can “fix” it. Going against that impulse can be very difficult.
A cancelled Sprint is an acknowledgement that the fundamental direction of the current Sprint is no longer the right thing to be doing. This can seem to be an insult to the team: why didn’t “you” get it right earlier? If there are certain people on the team who advocated strongly for the current set of work, they could take Sprint cancellation particularly hard.
Cancelling a Sprint may require undoing technical work and may be complex. If team members have made changes that they are particularly proud of, they may resist undoing that work more than would be called for simply due to the time involved in undoing it.

Once people experience these emotional effects from a cancelled Sprint, they will want to be cautious to avoid them re-occuring. That sense of caution will lead people to make arguments to the effect of “let’s make sure when we start our next Sprint that we have everything right” or simply, “I don’t want to go through that again… we better get it right this time around.” In order for the ScrumMaster to avoid falling for these arguments, it is important for the ScrumMaster not to be a hands-on contributor to the work. In other words, to be emotionally detached from the work. Those arguments can be persuasive unless the ScrumMaster can remind the team about empiricism. The ScrumMaster must always support the Product Owner if the product owner believes that a cancelled Sprint will lead to the best business outcomes.

Scrum is an empirical process that allows for “failure”. Of course, it probably helps to not call it that. Instead, a Scrum Team and the organization around it need to think of every Sprint as an experiment. There’s a good analogy here with the various stages of drug trials. When a company wants to research a new drug, the drug will go through various stages of experiments. The early stages of research are based on chemical reactions in the proverbial test tubes – laboratory experiments. Subsequent stages of research are often based on animal experiments. After that come human trials. At any stage if the drug in question is showing adverse effects outweighing the therapeutic effects, then the current stage is cancelled. Of course, the research done to that point is not a waste, but nor does it immediately result in a useful drug with net therapeutic effects. In Scrum, each Sprint is like a stage in the drug trials. If the work of the Sprint will not result in a net benefit, it only makes sense to cancel the work as soon as that information becomes obvious.

Waiting for Perfection

The pitfall, then, is that after a cancelled Sprint a team will feel pressure to wait until conditions are perfect before continuing on the next Sprint. Scrum does allow for the team to do a bit of a review of the reasons that the Sprint was cancelled, perhaps even to do a retrospective, and then start another Sprint planning meeting. The Sprint Planning meeting might be a bit longer than usual. The ScrumMaster does need to be sensitive to the needs of the team.

Cancelled Sprints and Synchronized Teams

One other factor may be a consideration: if the team is working with other teams on a larger-scale effort, there may be pressure to have all the teams with synchronized Sprints. For example, the Scaled Agile Framework emphasizes cadence and synchronization among multiple Scrum teams. In this case, a cancelled Sprint may mean that a team sits idle for a short time while they wait for the next synchronization point, as illustrated: