TL; DR
The Sprint Goal must not be changed during an iteration. Changes that would prevent the Scrum Team from reaching the Sprint Goal must terminate the sprint. The rest is just an accounting exercise that helps the organization understand the cost to the project for scope changes made mid-iteration.
When Scope Changes Mid-Sprint
Scope changes really require a conversation between the development team and the Product Owner, mediated by the Scrum Master. Scrum is designed such that scope changes should be made during the inspect-and-adapt inflection points at the start/end of every iteration, rather than mid-sprint. However, Scrum provides several mechanisms for managing just this sort of issue.
While it is certainly possible for the development team and the Product Owner to cooperatively modify stories—so long as the modifications don't prevent the Scrum Team from meeting the defined Sprint Goal for the iteration—stories can't just disappear from the sprint. They must be accounted for, as scope change must always remain visible and transparent to the entire organization.
Here is the typical decision tree for how to handle removal of stories from a sprint:
The development team and the Product Owner may agree that the story can be incomplete without compromising the Sprint Goal.
If the story is already completed, then the story is "done" and counted in the velocity, whether or not the feature is used. This will correctly reflect the work completed within the sprint.
If the story is not 100% complete in accordance with the "definition of done," the story is simply "not done" and no story points are awarded in the burn-down. This will correctly be a drag on velocity because it represents resources taken away from other stories.
The Scrum Team may determine that the user story is essential to the Sprint Goal, which requires the Product Owner to call an Early Termination to the iteration and a return to Sprint Planning.
- Early Termination makes it explicit that the scope has changed radically enough to invalidate the plan for the current sprint.
- Early Termination correctly adds visible overhead to the overall project. Dramatic scope change isn't free; that's why the process makes the cost of interrupting an explicit cost for which the Product Owner is responsible.
- You can often skip the Sprint Review with an Early Termination, but don't skip the Sprint Retrospective or Backlog Grooming before returning to Sprint Planning.
- Only stories that are complete per the "definition of done" will be counted in the aborted sprint's burn-down. Because the sprint is a non-standard length, this may be a blip in your data, but it still accurately reflects the amount of work completed in the iteration. This is why velocity should be calculated as range based on trailing averages; it acts as a smoothing function that embraces even dramatic scope changes in the metric.
Educate About Change Control
Agile frameworks embrace change. That doesn't mean change is free. As long as you use the framework properly, change will be controlled, which is generally a key objective for any project management framework. As the Scrum Master, it's your job to educate the organization about how to use the framework to its best advantage. Hopefully, this answer will help with that.