Retrospective for Cancelled Sprint

Might it be a good idea for the team to find out why the Sprint had to be cancelled, and to inspect and adapt their process so that the chances of cancellation are reduced in the future?

Hi Ian,

It might be a good idea to have retrospective meeting for a cancelled sprint. But, I do not see the clear purpose, Reason is that Sprint cancellation happens in a market disruption, technology changes where current technology help no more solve the advanced problems/needs and sprint goal itself become not relevant. There is nothing much to do with process improvement and people. It will be enough for the product owner to say the reason why the Sprint is cancelled and what will be the light ahead which can enable the development team to plan up things like acquiring new skills, adjusting the team capacity, focus.. etc.. I am also thinking what could be the internal reasons for a sprint to get cancelled one reason could be sudden focus change of organization building this product due to fund constraints or suddenly realized building the current product is no more relevant in view of the stakeholders.

Are you sure that these things have nothing to do with process improvement and people? Don't you think a Scrum Team should be able to master disruptive innovation or technology changes?

If any of the things you describe happened, shouldn't it be a collaborative *team* which evaluates the information, inspecting and adapting their ability to frame and meet future Sprint Goals accordingly?

Worst case scenario is that the reason the Goal became obsolete was completely out of the team's control.  A Retrospective still seems useful to discuss the Sprint's process up until the point of cancellation and to discuss how well the team reacted to cancellation.  

I am not saying that retrospective should not be there when a sprint is cancelled. All I need to say that team might not have enough clue. The main purpose of having sprint is to produce software increment which in case do not happen. But, whatever happened till the point of cancellation, team might retrospect on the improvements and people side too. So, sprint retrospective is shortened/precise in this scenario.

The main purpose of having sprint is to produce software increment which in case do not happen.

It is oversimplifying to state that the main purpose of having a sprint is to produce a software increment, but your point is noted.

That said, I would propose the main reason for a retrospective is to support continuous improvement, and that goal remains regardless of whether the sprint is canceled or not.

I think it's important to realize that the team created the sprint goal.

Simply accepting the cancellation and move on sounds like a lack of self organisation and sense of ownership.