Sprint Cancellation and its effect on Sprint Review and Sprint Retrospective

If the Product Owner cancels a Sprint, it will no longer exist to contain a Sprint Review or Sprint Retrospective. Neither event would constitute a pre-condition to Sprint Planning.

In Scrum Guide we can find:

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. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. (...)

In the description of the Sprint Review:

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

In the description of the Sprint Retrospective:

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.

Summarizing it, IMHO regardless of canceling the Sprint, still, it is the end of this Sprint, so to "maximize chances for success" in the upcoming Sprint, the Scrum Team should do Sprint Review and Retrospective as usually.



Nevertheless, it may look different from what the Scrum Team used to, as i.e. invited participants may be different or in a smaller audience or even limited only to the Scrum Team (as it is up to the PO to invite other stakeholders).

Two interesting perspectives from the above.

@Ian Mitchell, I can understand why a Sprint Review might not make sense but would a Sprint Retrospective not hold value in such a situation before regrouping in the next Sprint Planning. Your point about the Sprint ceasing to exist and thus the events is a strong point though. Personally, I am aligning with that view as I consider it would be a forced upon situation if a Scrum Team were asked to have those events no matter what. I consider it an unnecessary overhead if the direction or goal becomes obsolete.

As I never experienced Sprint cancellation, I imagine that it may look like this:



PO says to the other Scrum Team members that it is no longer worth to pursue the Sprint Goal, so the whole team will decide that we should stop what we are doing, review what we have done and adapt the product backlog if necessary (aka Sprint Review), inspect why we find ourselves in such situation and decide improvement(s) to eliminate or limit such situations if possible (aka Sprint Retrospective).



I imagine that as it may occur in a short time-box and by conducted with limited participants, it may be hard to distinguish and assess that in fact, we performed Review and Retrospective, but I believe that it is most likely human behaviour in such situation. Or in other words, Sprint Cancellation may put us in a moment in "Chaotic" quadrant of Cynefin, where we first Act (stop the work) then Sense (inspection the situation around) and Respond (regroup at new Sprint Planning).

I have experienced multiple cancelled Sprints.

I have always tried to use these as learning opportunities. I would want the team to reflect upon how it ended up in a situation that cancellation was necessary.

In one case (probably the most traumatic cancellation), there was a strong emotional reaction towards the CTO who had heavily pressured the Product Owner to cancel the Sprint, just a few hours after we'd had Sprint Planning. We took probably 90 – 120 minutes to retrospect on this as a Scrum Team. At the end of the retrospective, we decided to invite the CTO and share our views and how his intervention had made us feel. We talked further, and it was a growth moment for the team.

In other cases, the team (Product Owner included) were blindsided by changes in priority. Often these surprises could have been managed in a more structured way, had we had better communication.

There was generally discussion within the team in the run up to the Product Owner deciding to cancel.

Because of this advance discussion, it sometimes didn't feel necessary to have a retrospective, because we knew the reasons, and there was seemingly nothing new to learn.

With hindsight, I believe not making sufficient time for a retrospective was a mistake.

And I even had feedback from a developer once that she missed having that calm moment to reflect on how we got there, and how to turn it into an improvement opportunity.

As for Sprint Reviews, it depends what still needs to be learned, but if the Product Owner has already decided to cancel the sprint, in most cases I would expect there is enough confidence about the immediate future direction of the product that holding a Sprint Review is not an immediate priority. Perhaps it's sufficient to discuss the cancelled sprint at the next Sprint Review

PO says to the other Scrum Team members that it is no longer worth to pursue the Sprint Goal, so the whole team will decide that we should stop what we are doing, review what we have done and adapt the product backlog if necessary (aka Sprint Review), inspect why we find ourselves in such situation and decide improvement(s) to eliminate or limit such situations if possible (aka Sprint Retrospective).

@Piotr Górajek, That's a good point, however, the assumption here seems to be that the team is creating an Integrated "Done" Increment almost every day. What if the work was not Integrated into an Increment? Would it then make sense to pursue that when a Sprint cancellation is imminent? It would tie back to the below excerpt you quoted from the Scrum guide right?

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. 

@Ian Mitchell, Curious to know if it would make sense to have a Sprint Review and Retrospective in certain scenarios.

Curious to know if it would make sense to have a Sprint Review and Retrospective in certain scenarios.

These events are formal opportunities to inspect and adapt product and process. I'd suggest that a team might be wise to do both before any decision to cancel is made.

@Steve Matthew Like in any other case - it depends. People involved in such a situation should maintain a common sense. It is hard to write down exactly what to do to cover the whole complexity of humane work. Let's say that you have not integrated work into an Increment (it is not "Done"), but you feel it is "so close", I bet that whoever put effort into work, will highlight it by simply asking "Can't we just finish this within the next few hours? It is almost ready, etc.", there is hidden re-estimation act, which IMO is close to reviewing a thing (if not equal to that action - how you can (re)estimate something without reviewing it?).

(...) All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog.

The order of actions may vary, but they most likely will still occur.

My point of view is that in such a situation we do Review, and we do Retrospective, regardless if we name it like that or not. It may look different from the common way of doing it in that team, as this is a "special occasion" though 😅

I am also not convinced that canceling the Sprint results in its being wiped out of existence, i.e. it magically disappears.

IMHO It simply is equal to ending the Sprint before the original time-box runs out, it is a special kind of ending, but still, it requires some actions and effort, even extra one, to make that cancellation happen.

@up I mean: (...) the whole complexity of human work (...)

Hello, both Piotr and lan's arguments are quite logical since : 

• When we cancel a sprint, that's mean we no longer have a current sprint, and we should move to the sprint planning (to plan the next one) 

         "..Since everyone regroups in another sprint planning to start another sprint" 

• But after cancelling a sprint, considering the cancelling here as the shorteness of its duration, it's may be benificial for the team to inspect themselves in the sprint retrospective. 

But what about the sprint review, since the PO explain what PBI have been "done" and what has not been "done" ?

 Thanks, 

A bit dated discussion that I have just come across. Everyone is presenting a reasonable opinion with varying degrees of correctness. This is the beauty of Scrum that it is a framework and there is a lot of flexibility in it as well as knowing what to do is based on empiricism. Therefore, every company, team, project, and situation will dictate a different approach. 

The above discussion focuses on the project and the scrum team, with no mentioning of the stakeholders and the importance of communicating with the stakeholders in order to achieve transparency. 

Therefore, in my opinion, if a sprint is cancelled, regardless of its stage or maturity, I would hold the Sprint Review to discuss with stakeholders what has (not) been done, what changes have occured at team level, org level, financial level, or market level that led to the cancellation; then I would solicit feedback from the stakeholders with regard to the situation and the levels mentioned above. Let's not forget that Scrum events are for inspection, adaptation and asking for feedback in between. So before jumping to look at the SBL or PBL I would do this and on the light of the discussion and I would review, update or amend my SBL or PBL in terms of items and goal. 

Also, I would still hold the Sprint Retrospective because it is a valuable opportunity to reflect and to learn from what has happened and to look forward in order to avoid same scenario if possible, to mitigate the risk of repetition, and to find out how we can serve the stakeholder in a better way. 

As an older thread, I believe the 2017 edition of the guide was being referenced, where there was guidance included on how to handle a cancelled Sprint.

This guidance was removed in the 2020 version, with the only mention now being...

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

This opens it up to the Scrum Team to decide what comes next should a Sprint Goal become obsolete, and the PO decide to cancel a Sprint.

Aiman, I like your empirical tie-in for how you would handle a cancellation. A cancellation ought to be a very rare thing, and a thing worth inspecting should it happen.