I assume that every Scrum team has been at this point: The scope of a sprint needs radical alteration because of one of many factors. What to do now? In my experience there is only one way to handle this event as good as possible while adhering to the framework that Scrum defines: Sprint Cancellation.

Is It Appropriate to Terminate?

Obviously this is the first consideration you should make. Throughout my career in Agile development I’ve seen quite some sprints being terminated; not all of these decisions were reasonable though. Some teams may consider a cancellation just because of slight changes or uncertainties either in scope of the sprint or in their original estimations. I truly believe that a Scrum team that has some experience should be able to cope with minor alterations that occur during a sprint. The Scrum Guide tells us that these things about a Sprint (Scrum Guide, p. 7):

During the Sprint: No changes are made that would endanger the Sprint Goal; Quality goals do not decrease; and, Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

So, sticking to this, I see that minor changes are acceptable. Scrum – or Agile – by definition recognises that your knowledge about a project is always vaguest in the beginning of a project. This is why we do Sprint after Sprint and adjust everything to our current level of knowledge. By referring to the basic hermetic principle of As above so below this also applies to Sprints as they are nothing more than very small projects for themselves. So in the beginning of a Sprint our knowledge about what we are to do is vaguer than it is at the end of a sprint. Thereby it is only to be expected that we will uncover alterations to what we planned in the beginning. As I see it, as long as these alterations do not endanger the overall goal of a sprint in general and would not require us to dramatically lower quality expectations there is no reason to terminate a Sprint prematurely.

A good indicator for cancellation though would be a dramatic shift of the scope as I experienced it just lately. When it is obvious for example that it is necessary to completely drop the current Sprint Goal because of changed priorities (e.g. delivery of a feature has to be earlier) you should truly consider a Sprint Cancellation when there is no way you could make it in time otherwise.

What Would be the Impact?

As stated before I believe that this decision has great impact on the mental and emotional resources of all stakeholders. Calling for a termination often causes emotions boiling over and in turn causing heated and sometimes unfair arguments about who is to blame. Carefully take into account the current emotional situation of the project. Although this is something we are told to ignore most of the time in business, it is crucial in this situation. If people are already very unhappy or even angry at one another because of the current status the Sprint Cancellation may cause the accumulated pressure to be released under very bad circumstances. Additionally the mental impact is not to be neglected as well. Reorganising the mess that this termination will leave behind really strains your brain. You will need to be quick with re-evaluating your backlog, changed priorities of features and getting the next Sprint on track again.

Of course there is also what I would call the business impact of the decision. All the discussions, meetings and work that will be caused by such a measure will of course directly translate to money. So if you are a more business-oriented instead of people-oriented person see it like this: Sprint Cancellation is expensive!

Who Makes the Decision?

If you are certain about stopping the current sprint you need to figure out who is in power to do so. As the Scrum Master is the owner of the process you could easily think it’s his or her decision. But I don’t think so. As Mike Cohn points out in one of his posts at mountaingoatsoftware.com called Making the Decision to Abnormally Terminate a Sprint he advocates for the Product Owner to be the one in charge, because essentially he or she is the one responsible for the product and thereby the only one who could decide about the impact of this decision on the product (my words not his!). The Product Owner is responsible for committing to this decision, but all stakeholders that will be affected by it should be heavily involved in the decision making itself. This increases transparency by clear communication and so it can be possible to cushion the impact of the termination at least a bit.

How to go on?

I think that there are many ways to continue after the Sprint was stopped, but the best one would be to do a Scrum like they do in Rugby. The Scrum Master should get everyone together who was hit by the impact to find out where things went astray and how to prevent this for future sprints. Once this Emergency Retrospective is over reduce the number of involved stakeholders to those that are really necessary and figure out the next step; I’d suggest to involve the Scrum Team and a representative of the customer. Two widely known ways are to either continue with a normal-length sprint or a short Sprint. I think the second option (short Sprint) is feasible when you cancelled the Sprint within the first few days so that you could easily get some work done until it would usually end and so you do not get out of the already learned heartbeat.

Very often you will need a day or so to get things sorted out again. The Product Owner should re-evaluate the Product Backlog in collaboration with the customer and the team could certainly use that time to tidy up loose ends that ware caused by the termination. Afterwards, when priorities are clarified, you should kick off with an Estimation or Grooming Meeting followed by a Planning as soon as possible so you do not lose more time than necessary. However these are details that you should discuss as a team in collaboration with all necessary stakeholders. The most important part is this one:

Do not lose faith just because a Sprint failed. Sometimes things like these happen. Instead of mourning over it, use it as a chance to learn a great deal about how you work as a team and how to improve it.