Sprint goal obsolete

Just my thoughts on the subject.   I'm sure there are many others.

when the sprint goal becomes obsolete... Any real life examples?

Thankfully, I've never participated in a true sprint cancellation.   There can be valid reasons for doing so though, mainly around value as managed by the PO:   

• Let's say the team was working on an application when management made a mid-sprint decision that they were going to decommission it.   Now, would it make sense for the team to continue developing something that was not going to be released, or would have a very short shelf life?
• Or, let's say the PO realized they made a poor choice in their recent sprint offering, and there is a different initiative ready to go that has far more marketplace and customer value than what was offered.   Would it make sense for the PO to pull the plug on the current sprint in favor of the better option?   Maybe, but the PO needs to weigh the advantage of "stopping the line" as opposed to finishing the current sprint and introducing the more valuable initiative for the next sprint

Any incomplete Sprint Backlog items are re-estimated (remaining effort) and placed back into the Product Backlog.

The Scrum Team commences a new Sprint Planning session to refocus the Development Team on the new direction.   Ideally, this abbreviated sprint should end when the canceled sprint would have, in order to still adhere to the original cadence.

I would highly suggest a Sprint Retrospective be held in the event of a Sprint Cancellation, since nobody wants to repeat such an event, and it is critical to understand the root causes for such a cancellation.

Keep in mind that even the Scrum Guide refers to Sprint Cancellations as "traumatic" and extremely rare.   Cancellations are complete outliers to the typical Scrum experience, and it is best to not spend an inordinate amount of time considering the event and its repercussions.

There is a subsection in the Scrum Guide's section on the Sprint that has some of your answers. 

https://www.scrumguides.org/scrum-guide.html#events-sprint

You asked for an example. This occurred a while ago but it is a good example.

I had a team working on day 2 of their 3rd sprint for a set of product upgrades.  We had delivered 2 increments of value and had some positive feedback from our stakeholders.  Our Product Owner came to the Development Team following their Daily Scrum.  He had just been informed about this new thing known as GDPR which in essence invalidated the entire set of product upgrades that we were pursuing. We immediately canceled the sprint, gathered at our desks , put together a new Backlog Refinement session to review some Product Backlog Items that were below the invalidated stories but had not been properly refined.  (This took a LOT longer than our normal refinements sessions).  Immediately following the refinement session, we did a Sprint Planning.  We decided to keep our normal cadence of planned events mainly because getting conference rooms in this company is next to impossible. So in essence we shorted our sprint by 3 days and then shifted back to our normal 2-week cadence. 

Remember that canceling a Sprint should be rare and for significant reasons. Sprint Review and Retrospective is usually not necessary because if a Sprint is canceled there is no increment to review and everyone should know very well why it was canceled.

Does that help? 

Thanks Timothy and Daniel! A real life example always helps me understand and later remember something I am learning!

The Scrum Guide says: "In general, a Sprint should be cancelled if it no longer makes sense given the circumstances."

If the Scrum Framework can no longer be implemented, then Sprint cancellation may be necessary. There could be management interference for example, such as team members being forcefully re-allocated mid-sprint. If the Development Team and Scrum Master cannot resolve the situation, or adapt the Sprint Backlog so the Goal remains achievable, then it would be incumbent upon the Product Owner to take action and to minimize losses. In theory this ought to be an obscure edge-case of Sprint cancellation, in practice though it is fairly common.