What do you do when a sprint is cancelled?

What do you do when a sprint is cancelled?

All the standard Scrum certifications (CSM, CSD, CSPO) pay little attention to the fact a sprint can be cancelled. At best you will get a single slide and the trainer reinforcing the idea that the Product Owner is the only one who can make the call to cancel a sprint. This is common when there is no valuable software increment that can be delivered because of some significant change, scope, market, personnel, etc.. In this article I cover some key questions and challenges that are likely to come up from the team when a sprint is cancelled.

I started thinking about this topic recently when a team I was working with had a sprint cancelled. For context, the team have a well defined definition of done, which includes the fact that each story should be deployed and tested into an integrated environment. The PO would not sign off stories that were only running on a developer’s machine. This time the hosting solution for all the integrated environments went offline and were not due back online until the end of the sprint. The developers carried on with stubs, mocks and local automated tests.  Pretty soon it became apparent that the PO was not willing to make the concession on quality and sign off work they had not seen running in a “proper” environment. The team understood and agreed, then the discussions started.

What to do with the work that is already done?

Well the answer is, as with many things in this world, it depends.

In this instance the team had already completed a few stories and the project was due to continue so it was no problem to leave them in the code base, the value still remained. Other teams, those with mature CI/CD pipelines have an advantage here, may be able to push their completed stories out to their users.

• If there is still value in the already completed work then use it to your advantage

In other businesses the value of the work will no longer remain, for example if requirements have changed significantly. This may be a tough decision and meet some resistance as the team will have invested themselves in that work but with some explanation they should come around. It is the PO’s call after all.

• If there is no value in the completed work, don’t be afraid to throw it away

What to do with the work in progress?

You may not be surprised to hear the answer again is, it depends.

For the team I’ve been working with the developers carried on for a few hours making sure the code was in a suitable state to be left. They knew that they would be coming back to the code so used GIT to stash the changes for the next sprint. This was because the value would still remain and they knew that they are highly likely to pick up the majority of the unfinished stories in the next sprint.

Another PO may decide there is no value in the work in progress so the team should throw this away, a tough thing for some.

• If the value remains for the work in progress then find a way to store it safely. The items may not be picked up in the next sprint, or ever, don’t let them become technical debt
• If the value is no more, then throw it away, hard as this may be

Again this second option has the potential to frustrate a team. The SM and PO need to communicate the business value has gone. The team should be responsible enough to clean up their work environment so the WIP is not a burden later, the SM may need to prompt them on this one.

The second option has a real chance that it will demoralise a team. They have worked hard on these things and now the PO is throwing them away. As SM you must communicate to them that the work has lost its business value, while it may contain some great technical work, and it will ultimately end up being technical debt.

What to do with the remaining time?

There are a couple of options here but I think for the majority of teams the first is not practical.

If the backlog is well refined and prioritised then in theory the team could start a new sprint immediately.  In practice this is unlikely to work as there is a cadence that will have formed around the sprint cycle, there will be meeting room challenges, stakeholder comms and other teams to think about. It is probably not worth the effort.

• If you can start another sprint, do; this may be hard though and should consider the impact of doing this

Instead the team I was working with decided to do what they called a “mini sprint”. In truth this was more an exercise in kaizen, they created their own backlog of improvements to make to the code/tests/their work environment etc.. They used a kanban board to visualise the flow, and became their own product owners for some of the items. Other teams may choose to do a hackathon, bug smash or knowledge sharing exercises.

• If you are not starting another sprint then make use of the time, look for those things that always come up in the “if we ever get round to it” conversations

After cancelation of a sprint the team are likely to be pretty demoralised. Their hard work has been thrown away. Those hours refining, designing, building each increment may be for naught. The aim with bringing together the team to produce something of value to them. Without a conscious decision to make the best of the bad situation the team may have whittled away the working day, picking up the odd bit of work but mostly moped around feeling demoralised.

This is really the main point of this blog and why I’ve mentioned the team morale at the end of each section. The team I was working with were pretty down about the experience even though they saved all their code for later sprints, they wanted to continue to add value after all. The brain storming and subsequent actioning of many items that they had in the back of their mind was a big energiser. Doing some form of organised work was making the best of a bad situation.

Do we still have stand ups?

If you are no longer “sprinting” I still think there is value in hitting the main Scrum ceremonies. The stand ups change a little in this context, since they are not about alignment to a sprint goal, but they are still valuable and help foster a sense of “team”.

I would be cautious to run the usual form of sprint review. It’s likely to be a painful session with many angry stakeholders. They may direct their anger at the team which could be very destructive. You may want to have a small session with the team to demonstrate and discuss their improvements with technical stakeholders or other teams.

As for the retrospective this should still happen. I’m sure there will be much discussion around the nature of the sprint cancellation. Could the team have helped prevent it? You might be surprised after such a painful experience how willing people will be to look to improve.

The other activity that is not part of the core ceremonies, but absolutely should still continue, is refinement. Assuming that you have not stopped development on the product completely. You are likely to be carrying on with some form of development. The backlog will still need to be in a suitable state for this work to continue.

• Carry on with your sprint ceremonies to foster team confidence, but be cautious of sprint reviews, there is no product to ”inspect & adapt”

There is something to be said for maintaining the regularity of the ceremonies. Stand ups and retros foster a sense of “team” and will help identify solutions to interesting problems. Some form of technical review can ensure a team can show off the improvements they have made.

The wrap up

For a Scrum Master the biggest challenge when a sprint is cancelled is that team morale is likely to drop off significantly. Team members are likely to have a negative reaction to the PO and the product. By saving what you can and communicating why other things cannot be saved hopefully the team will be comfortable with the cancellation.

Most teams are unlikely to be able to start a new sprint immediately. Instead opting to maintain a sprint heartbeat consistent with what they are used to.

Using the remaining time to generate something useful for the team is a wonderful chance. It will get the team working together on items they are interested in. They should get a boost from this but there is also a good chance for a “foot off the gas” moment, especially when a team has been working on a project for a longer period of time.

Still sticking to the core ceremonies will bring a sense of familiarity to the team. It should also avoid the idea that people can completely cruise the remaining few days.

Learn more and get certified!

Become a Certified Product Owner on our highly-impactful and certified agile training courses in London and online.