According to the Scrum Guide, once a Sprint begins, you are not supposed to change the Sprint Backlog for any reason. Discovered work related to the stories that the team committed to is ok, but new stories are not ok.
Is this realistic, or is it too strict for real-world scenarios?
This is highly debatable based on my own experience working with different organizations.
So, the best answer is…it depends!
If your team is running short sprints (2 weeks), it is typically much easier to convince the stakeholder/requestor to wait a week so that your team can focus on finishing the planned work. This is one of the main benefits of following a shorter sprint cycle. Longer sprint cycles add risk of more potential interruptions, which is exacerbated by longer waiting time for your stakeholders between sprint timeboxes to get new work added.
If you are a Scrum purist, you may try to deny all changes to the Sprint Backlog while a sprint is active. However, you may want to consider “trading stories”; if the stakeholder has an urgent request (estimated at 5 story points), you could ask the team to explore the possibility of swapping this new work with another 5-point story that has not yet been started, assuming that this new work would not have significant impact to the solution architecture/design.
The only thing we know for sure is that change will happen no matter what, so it is up to you to handle it in the best way to balance team focus with stakeholder satisfaction.
Dig into how to create better User Stories by reading another one of our latest blogs Refinement - What's the Point?