Requirement change cannot be avoided, what can we do in this case?
When the sprint backlog for coming sprint or sprint targets are finalized, to make sure the team is focusing on the targets, usually the team doesn't accept requirement changes from the product owner. Normally, the product owner is responsible for organizing the sprint backlog ahead of time, therefore, frequent changes won't be accepted by the development team. It also helps the product owner to properly clear the potential risks.
Changes cannot be avoided, sometimes requirements will change. What to do if it happens? When it happens, don't say yes or no, analyse the new requirements first, find the impacts on the current sprint. Usually, there're the following cases:
Discuss with the product owner, see if it's a valid requirement or not. If invalid, say no to the changes.
For a high-priority change, which has a small impact on the current sprint, it's OK to accept. We need to estimate the effort, swap tickets out from the current sprint, and add in new tickets, to make sure the team won't be overwhelmed, although small change. For the ticket that swapped out, usually, move it back to the product backlog.
For a high-priority change, that has a big impact on sprint. There're two cases. First, tickets in the current sprint won't create much value. In this case, we need to abort the current sprint. In the second case, the requirement changes need a large amount of effort to deliver, we need to abort the current sprint as well.