Sprints are mini projects that help us tackle our main project. But what happens if we decide to cancel one of them? The option of canceling a sprint is clearly stated in the scrum guide. So, let’s go a step back and look at the definition of a project:
A project is a temporary endeavor with a clear beginning and a clear end. At the end we expect specific goal objectives to have been achieved. It could be a product or a service.
The sprint has also a clear beginning, a clear end and an objective: the sprint goal. So a sprint is like a mini project. I’m sure most of you have experienced a failed project. Projects can fail and so can a sprint.
What is a good reason for actually canceling a sprint? Let’s say the development team suddenly comes across to some technology issues. Could be architecture infrastructure, maybe some requirements turned out to be harder, not as well understood as they thought they are, or something else. Is that a good reason for cancelling a Sprint? Well, I don’t think so. I would expect from a real professional development team to struggle, get together, weigh the options, talk to people. To always look at the Sprint goal and try to find out what options are still available.
What is then a good reason for cancelling a Sprint? Let’s move from the outside in.
Let’s examine the overarching objective goal we wanted to achieve, the product we wanted to build.
If the sprint goal becomes invalidated, then yes, that’s a very good reason to cancel a sprint.
That’s probably also a reason to cancel everything, drop your work and look at what are the next best things to do.
But now the sprint goal is nearly gone and even if we could achieve the sprint goal in half the time it would be of no use anymore.
Because the sprint goal would be useless. Invalidated. That’s a good reason for cancelling a sprint. In my opinion that’s the only valid reason for actually cancelling a sprint.
Canceling a sprint is not for free. It causes costs.
We have brought people together to work, we might have to talk to stakeholders, may do some investigation as to what triggered this event. The development team would only look at the product’s backlog items deemed to be done, investigate whether it’s worthwhile to integrate them into the product, estimating the incrementation of the remaining product backlog and put it back in the product backlog.
All of this has a price sticker. Since the product owner is the role which is in charge of the budget is in the drum, only the product owner is empowered to actually cancel a sprint.
So canceling a sprint is a dramatic event for the development team. It leaves scars. So it is a tool you have in your toolbox but it should be used really really wisely.