I’ve been asked this question by others in the agile community, who have done some agile training but still have no idea how to go about cancelling a sprint.

Why cancel?

There are several reasons why you might be considering cancelling the sprint - it could be a change in scope; a major incident with another product; the realisation that the sprint goal is unachievable or something else entirely.

When to cancel?

If someone within the sprint team believes that the sprint should be cancelled, they should raise this with the ScrumMaster as soon as possible. The latest they should raise their concern is at the daily standup ceremony the following morning. After raising the concern, the entire sprint team should have a discussion about possible options. If the team acknowledge that there’s no other option but to cancel the sprint, it’s the SM’s duty to ensure the Product Owner has sufficient understanding to make the decision to cancel the sprint. 

An example from my own experience is when the business stakeholder didn’t engage with the PO enough before the sprint. Halfway through the sprint we realised that the PO and customer had completely different opinions on what was to be delivered. If we had continued on the sprint the customer would’ve ended up with something they really didn’t want and would lose faith in our development ability. For this reason, it was crucial for us to cancel the sprint and to re-plan with the stakeholder and PO physically present in the same room.

Can a Scrum Master cancel the sprint?

No. Some people might disagree with me on this, but hear me out. The Product Owner represents the business, and so there may be a conflict of interest if the SM starts cancelling sprints. Sometimes the PO will require the team to do the less fun work, and if the SM has the authority to cancel the sprint on behalf of the team, the legacy code - which also is seen as high value to the business - may never get a look in. 

It’s the SM’s role to advise the PO on their decision, and to present the pros and cons of continuing with the sprint or cancelling at this point. The PO may decide not to cancel, but to instead revisit the stories and priorities of the sprint, but this may not work in all cases. The PO wants to ensure that business value gets delivered, and should respect the team and SM when they are telling him/her the “why” it is necessary to cancel.

OK, so we’ve cancelled the sprint, now what?

This depends on when you’ve cancelled. If you’ve been on the sprint for more than one day, I believe it makes sense to have a retrospective before moving on. 

What to do with work already completed?

If there is still value to the business in releasing this work, and it isn’t dependent on other stories that are no longer going to be worked on, you may be able to push completed work out to the users right away; or let it remain in the codebase if the dependencies will get worked on at a later date. If the business requirements have changed, be brave and throw the work away if it won’t deliver value.

What to do with work in progress?

If the work will be revisited soon in an upcoming sprint, the PO may decide that this work is still valuable. In which case, I usually ask the developers to create a Git branch for the work they’ve done and push it up to the remote. If the work is no longer valuable, there’s no point keeping it and letting technical debt accrue. Again, be brave and throw away work that is no longer going to deliver value to the business.

OK, will we go home until the next sprint begins?

Haha! The developers I work with would love a holiday like this. Morale is often quite low after cancelling a sprint, but that’s no excuse to twiddle your thumbs as you await the next sprint. The SM should be able to identify what the team needs - it may be an hour break, or some fresh air before reconvening and getting back on that metaphorical horse.

In terms of moving on after the sprint, usually there are a few options, but this will depend on your environment and the length of the sprint cycle.

Option 1: Start a new sprint

If it would not be too disruptive to start a new sprint, and the stories in the product backlog have already been refined, this is a good option. Perhaps the sprint was cancelled due to stories not being groomed enough - in which case, you can spend the time breaking these down into developer tasks (as a team). For many, the option of starting a new sprint is not viable, due to the PO needing time to liaise with stakeholders and the cadence of the sprint cycle could be disrupted, e.g. if you normally start a sprint on a Wednesday but are now starting the new sprint on a Monday this can knock the schedule of future sprints.

Option 2: Do a mini-sprint

It may not make sense to start a full sprint - you may have your sprint demos and retrospectives already booked in. This is a good option if you want to avoid disrupting your sprint schedule and the same stakeholders who were booked in for the cancelled sprint have already accepted meeting invitations. In this case, the SM would look at the capacity for the remaining days until the sprint would have finished, then work with the PO to decide on priorities and what stories could be delivered by the end of the mini-sprint.

Option 3: Clear up technical debt and bugs

This is the option I tend to favour. I allocate 2 days to support and maintenance every fortnight, but this focusses on the high value bug fixes and performance issues. I have set a cadence that every quarter of the year, there will be a sprint on cleaning up technical debt. However, technical debt still exists even with this cadence, so it’s good to have even more of an opportunity to address this. I like using Kanban for this type of work, but I know of others in the industry who continue to use Scrum or Kaizen for improving existing code.

What happens to the ceremonies?

That’s up to you as a team. As I mentioned earlier, I like to run a retrospective after the cancelled sprint to explore how the team are feeling and to minimise cancellations in the future. 

My team aren’t always on sprints - every 2 weeks there’s 2 days where we’re on support instead. Nevertheless, we still have a daily standup regardless of whether we’re in sprint or not - the team like the routine of this. I’m also a big advocate for cadences - having the sprint planning sessions, demos, retros, whatever other ceremonies you choose to run at the same time and frequency (e.g. our initial sprint planning happens every other Weds morning, and we have a story grooming session every Tuesday afternoon). 

My feeling is, if you keep the ceremonies at the same time, regardless of whether you’re on a sprint or not, people know to expect them, and the team tends to like the familiarity of this.