Unplanned work is treated in a lot of Scrum guidance as a rare disruption to be minimized. For many teams (anyone supporting a live production system, anyone in an organization with genuinely urgent customer escalations) it's a routine, recurring feature of the work, not an exception. The useful question isn't how to eliminate it, but how to handle it without quietly destroying the value of sprint planning altogether.
First, distinguish genuine urgency from someone else's poor planning
Not everything that arrives labeled "urgent" during a sprint actually is. A production incident affecting customers right now is genuinely urgent. A stakeholder's request that could have been raised during the previous Sprint Review, but wasn't, and now needs to happen "urgently" because someone forgot to plan ahead, is a different category of problem, and treating both the same way trains the organization to route everything through urgency rather than through proper planning.
Make room for it explicitly, rather than pretending it won't happen
Teams that experience recurring unplanned work but plan sprints as if it won't occur are setting themselves up to either miss commitments regularly, or to quietly under-deliver on planned work every single sprint without ever addressing why. A more honest approach: track the historical rate of unplanned work over several sprints, and deliberately reserve that much capacity when planning the next one, rather than committing 100% of nominal capacity to planned work and treating every interruption as an exception.
Have an explicit threshold for when the Sprint Goal itself is at risk
Some unplanned work is absorbable within existing slack. Some is significant enough that continuing to pursue the original Sprint Goal unchanged no longer makes sense. The team, with the Product Owner, needs an actual answer to "how much unplanned work is too much before we revisit the goal," not as a rule applied automatically, but as a conscious decision point that gets triggered rather than silently ignored while the team just tries to do everything.
Track it, so the conversation about it can be based on evidence
A team that can say "unplanned work has consumed roughly 20% of our capacity for the last four sprints" is in a completely different position than a team that has a vague, unquantified sense that "we're always getting interrupted." The first can have a genuine conversation with the Product Owner and stakeholders about the trade-off being made. The second is just experiencing frustration without the data to act on it.
Use the Retrospective to address the source, not just the symptom
If unplanned work follows a consistent pattern (the same type of production issue recurring, the same category of stakeholder request bypassing normal planning) the Retrospective is where the team should be asking whether the source of that pattern is fixable, rather than treating each occurrence as an isolated one-off that just needs to be absorbed again.
Unplanned work isn't a sign that Scrum is failing. Pretending it doesn't exist in the planning process, and then being surprised every sprint when it shows up anyway, is the actual failure.