How do you handle a request to change scope in the middle of a Sprint?

Question

IT Interview Practice · Accepted Answer

The default in Scrum is to **protect the Sprint Goal**: no changes should be added that endanger it. But Scrum is not rigid — scope can be *renegotiated with the Product Owner*, and a truly urgent change can be handled, with trade-offs made explicit.

## A decision framework

```text
1. Does the new request threaten the Sprint Goal?
     NO  → can it wait for the next Sprint? Usually yes → backlog it.
     YES → talk to the Product Owner about trade-offs.
2. Is it a genuine emergency (prod down, legal, security)?
     YES → the PO may cancel/replace work; something must drop.
3. Make the trade-off visible: pulling X in means Y comes out.
```

## Concrete example

Mid-Sprint, sales wants a "small" new report. The Scrum Master helps the team and Product Owner see it isn't urgent, so it goes to the top of the next Sprint's backlog instead of disrupting the current goal.

## Common pitfalls

- Silently absorbing extra work, blowing the Sprint Goal and hiding it.
- Saying a flat "no" with no path — the Product Owner can always renegotiate.
- Letting every stakeholder inject work directly, bypassing the Product Owner.

## Why it matters

Protecting the Sprint Goal is what makes Scrum predictable; constant injection turns Sprints into chaotic to-do lists.

Handling change through the Product Owner with explicit trade-offs keeps the team focused while staying responsive to real emergencies.

A decision framework

Concrete example

Common pitfalls

Why it matters

Related questions