First, separate genuinely urgent from loudly requested
Most interruptions are not incidents. They are requests that arrived with confidence. A practical filter is to ask what breaks if this waits until the next Sprint Planning, which is usually days away, not months. If the honest answer is 'someone will be annoyed', it is not urgent, it is a prioritisation conversation for the Product Owner.
Real production incidents skip the queue and should. Nobody needs a ceremony to fix a payment outage. Everything else benefits from thirty seconds of triage.
Make the trade explicit
Capacity does not expand because a request is urgent. When something comes in, something goes out, and the Product Owner decides which. Saying it out loud converts a hidden cost into a visible decision: 'we can take this in, and the reporting item moves to next Sprint'.
This single habit changes how stakeholders behave. When people see what their request displaces, roughly half of the urgent requests stop being urgent.
- Route every incoming request to the Product Owner, not to individual Developers
- Name what leaves the Sprint before agreeing what enters it
- Put the unplanned item on the board so the cost is measurable later
Protect the Sprint Goal, not the ticket list
If the interruption does not threaten the Sprint Goal, the Sprint continues and the team absorbs the change. If it makes the Sprint Goal obsolete, that is the one situation where cancelling the Sprint is the right call, and only the Product Owner can make it. Cancelling should be rare. Teams that cancel often usually have a goal that was never more than a label on a batch of tickets.
Then fix the pattern, not the instance
If urgent work arrives every Sprint, it is not unplanned, it is unmeasured. Count it for three Sprints. If it consistently takes a quarter of capacity, plan for a quarter of capacity. That is not surrender, it is forecasting with real numbers instead of hopeful ones.
Some teams rotate one person onto interruption duty each Sprint so the rest can finish committed work. It is not in the Scrum Guide, and it works, because it keeps the cost visible while stopping it from spreading across everyone's focus.
Not sure which of these is actually happening in your team?
The team assessment asks everyone the same questions anonymously and shows you where people disagree about how the team really works. It takes about twelve minutes per person.
Run a team assessmentFrequently asked questions
Can you add work to a Sprint after Sprint Planning?
Yes. Scope can be renegotiated with the Product Owner as more is learned. What cannot happen is someone outside the Scrum Team pushing work onto the Developers or expanding the Sprint Backlog without a matching trade-off.
Who decides whether urgent work enters the Sprint?
The Product Owner decides what is worth doing, and the Developers decide whether it fits and what has to move. Neither decides alone. Managers and stakeholders raise the request; they do not assign it.
Should we cancel the Sprint when priorities change?
Only when the Sprint Goal becomes obsolete, and only the Product Owner can do it. Most changes do not reach that bar and are better handled by swapping items while keeping the goal intact.
How much unplanned work is normal?
There is no standard figure, but teams that measure it usually find a stable range. Once you know yours, plan around it rather than treating every Sprint as an exception.