The Scrum method defines that the content of a sprint cannot be changed. But can a sprint be cancelled while it's done? I mean, it's unlikely to happen and probably shows really bad planning skills by the product owner and a really awful prioritization of the backlog, but if the features of a sprint are not useful anymore, can the whole sprint be cancelled? Have you seen something like this?
Edit: More generally, are the sprints and their content as sacred as the method recommend it?
Cancel a sprint? Been there, done that.
Being a slave to a method is never good, and sometimes, despite all the planning, things can go awry. Really awry. When that happens the sensible thing to do is get off the train before it plunges over the cliff. That way everyone can regroup, calmly analyze the situation, identify what went wrong, discuss ways to avoid such a thing happening again, and start anew. (Assuming it was avoidable - sometimes the wide world intervenes. Hacks, infrastructure disasters, clients going south etc etc.)
More commonly, however, I've seen a single team have their sprint completely re-arranged. Typically because team members were pulled to deal with an emergency/something high-profile cropped up. In this instance stories were re-selected for the remaining team, or re-written (ie. broken up) to better fit the remaining expertise.
Bottom line - sprints are a tool, a means to an end. Sometimes, for a myriad of reasons, they wont get you there.
This comes down to how you want to run the project and who will pay the 'cost' of the canceled sprint. In the end there can be valid reasons for just caning the whole sprint and 'shelving' all of the code created to date and starting again.
I would recommend getting the stakeholders in the room and ask the hard question - if we are going to cancel this sprint and throw away the work that has been done, who is going to cover the cost. This tends to either get the focus you need and you can reshape the sprint to salvage some/all of the work done or confirms your decision to cancel the sprint.
In the end, as Gary said, Sprints are a tool/set of rules. I like rules, they help guide develoers, customers and PMs to the right decisions - canceling a sprint can be the right decision and can often be better than moving the goals of the sprint in the long term.
Sprints can be cancelled as abnormal termination, for example the team could cancel if unable to reach goal. The next step is to have a new sprint planning meeting.
Sprints can and should be terminated if there is a legitimate business need for it.
Keeping the content of a Sprint static is good for your team's sanity and generally helpful for planning.
What it is really powerful for is protecting the development team from scope creep by stakeholders that may drive-by and ask for new features, etc... if each time this happens you mark that sprint as abnormally terminated you are creating a record to communicate to the rest of the management.
If you are reviewing your projects progress with the leadership and show that Sprint 15 and Sprint 16 were both terminated because Stakeholder Xyz requested additional features this will raise red flags to show that either planning is not adequate, the vision isn't clear/consistent or Stakeholder Xyz is mucking with the team too much.
Also, it will make clear the impact of adding new scope to a sprint to a Stakeholder and make them less likely to interfere, or to wait until the appropriate times to influence the dev schedule (e.g. sprint planning meeting).
Agile is not anarchy, but works by providing structure around agility and hence defining the limits to how agile you can be.
