I think every Scrum Team was at this point: because of one of several reasons, the scope of a sprint needs drastic alteration. Now, what to do? In my experience, for managing this event as well as possible when adhering to the framework defined by Scrum the only solution is cancelling the Sprint. Now the questions are: should the Scrum Team convene for a Sprint Review and Sprint Retrospective in the event of a sprint cancellation? or should they concentrate on inspecting the work successfully, adjusting the product backlog and going directly into Sprint Planning? In this post I will talk why a Sprint may be cancelled, and what would happen if the cancellation decision is made?
Reasons for cancelling a Sprint
According to the Scrum guide, 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. In the other words; Cancelling a Sprint is a value-based decision that is usually required when the Sprint Goal becomes irrelevant and remains with the Product Owner. Sprint cancellations consume resources, and for the Scrum Team are often difficult and are very rare. It is possible to cancel a Sprint because of the following reasons:
- A better technological approach has been found or a significant technological change is taking place that allows cancelling the current Sprint work.
- The Sprint Goal is invalidated by fundamental and immediate external (market) changes.
However, you should keep in mind that the PO cannot just cancel the Sprint because of stories that have a higher priority than what’s in the Sprint are to be finished. In other words, we’ve got more important things to do.
What would be the impact on sprint review and sprint retrospective?
Cancellation of the Sprint decision has adversely emotional impact on all stakeholders. If you have a reasonable reason to cancel a sprint, go ahead and do it. Cancelling a sprint is just an agile response to change that has happened. This should not be considered a bad thing or a weakness of the Product Owner and the Scrum Team.
According to the Scrum guide, when a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. So, if the sprint ended abnormally (cancel the Sprint), it’s still the end of this Sprint and at the end of each sprint, we have to have sprint review and sprint retrospective. Sometimes scrum team didn’t feel necessary to have a sprint review and sprint retrospective because they knew the reasons, and there was seemingly nothing new to learn. But, this is an opportunity for the Scrum Team to inspect and adapt. I have seen many cancelled sprints and I have often seen this as opportunities for learning. I think it was a mistake not to make enough time for a sprint retrospective. However, for the Sprint Review, it depends on how many items have been “Done” and potentially are releasable. Maybe, the cancelled sprint at the next Sprint Review is enough to address, this depends on the PO decision.
Please share your thoughts with me on this.
Take a minute to follow me on Twitter if you enjoyed this post and want to see more.
Leave A Comment