Protecting the sprint commitment from mid-sprint changes while honouring genuine urgency. Scope changes during a sprint are the single largest source of missed commitments — and the hardest to refuse politely.
▸ Try the interactive toolSprint scope management is the PM's discipline of protecting the team's sprint commitment from mid-sprint changes while balancing genuine business urgency. It's one of the most consequential disciplines in the execution toolkit, because scope changes during a sprint are the single largest source of missed commitments.
The hard part isn't refusing all changes — it's distinguishing the genuine emergency from the merely urgent-seeming, and handling each without either derailing the sprint or stonewalling the business. The default answer to 'can you just also fit in…' is no, or next sprint, because every mid-sprint addition has a hidden cost: it displaces committed work, breaks focus, and erodes the predictability that makes the team trustworthy. But the discipline includes a process for the rare true emergency — making the trade-off explicit rather than silently absorbing it.
Default: new requests go to the next sprint, not this one. For genuine emergencies: make the trade-off explicit — what committed work gets dropped to fit this in? Never silently absorb scope; every addition has a cost someone must own.
Mid-sprint scope creep is the largest source of missed commitments, and it accumulates through individually-reasonable 'small' additions that no one tracks the combined cost of.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Silently absorbing scope | 'Small' additions accumulate and quietly break the sprint. | Making the trade-off explicit forces the real cost into view. |
| Saying yes to everything | Every urgent-seeming request derails the committed work. | A 'next sprint' default protects the commitment by design. |
| Saying no to everything | Stonewalling genuine emergencies harms the business. | A trade-off process handles real emergencies without chaos. |
| Eroding predictability | Constantly-changing scope makes the team un-trustable. | Protected scope keeps commitments — and trust — intact. |
When something arrives mid-sprint, the starting answer is 'next sprint.' This isn't obstruction — it's protecting a commitment the team already made. Most requests can wait one sprint.
A true emergency is rare — a production incident, a legal deadline, a critical customer escalation. 'Someone wants it sooner' is not an emergency. Be honest about which is which.
If something genuinely must enter this sprint, name what committed work gets dropped to make room. Scope isn't free — fitting X in means Y comes out, and the requester must own that trade.
Non-emergency requests go to the product backlog to be prioritised for a future sprint, like any other work — not jumped to the front because they were asked loudly.
The team shouldn't be exposed to the scope pressure — the PM absorbs it (the shield role, Tool 16), so the team keeps executing while the PM handles the trade-off conversation.
Midway through a sprint, a stakeholder pushed hard for 'one small addition' framed as urgent. The instinctive options both felt bad: say yes and silently break the sprint, or say no and seem unhelpful and rigid.
The discipline offered a third path. The PM didn't refuse outright or silently absorb it — they made the trade-off explicit: 'we can fit this in, but it means dropping the committed work on X. Which do you want?' Faced with the real cost, the stakeholder realised it could wait a sprint after all. The few times such a request is a true emergency, the same conversation cleanly swaps it in for lower-priority committed work, with everyone owning the trade.
The deliverable is a consistent protocol: default to next sprint, reserve this sprint for genuine emergencies, and always make the trade-off explicit.
| Request type | Response |
|---|---|
| Routine 'can you also…' | Next sprint — to the backlog, prioritised normally |
| Urgent-seeming but not critical | Next sprint, or explicit trade-off if pushed |
| Genuine emergency | Explicit trade: what committed work drops? |
| Anything | Never silently absorbed — the cost is always named |
Scope management is mostly the art of the explicit trade-off. The damaging move is never 'no' — it's the silent 'yes' that absorbs new work without anyone acknowledging what it displaced.
The reframe that makes this tractable is treating scope as a fixed budget rather than an expandable one. Within a sprint, capacity is committed; adding anything means removing something, and the only honest question is which. A PM who internalises this stops experiencing scope requests as a yes/no loyalty test and starts handling them as priority decisions: 'we can do that, here's what it costs, you choose.' This protects the team's commitment (and the predictability that earns trust) without ever stonewalling the business — because genuine emergencies still get in, they just get in honestly, by displacing named lower-priority work rather than by magically expanding the sprint.
The largest source of missed sprints. Make every addition's cost explicit.
'Wanted sooner' isn't an emergency. Reserve mid-sprint entry for genuinely critical work.
Stonewalling harms the business and your relationships. Offer the explicit trade-off instead.
The PM should absorb the negotiation (Tool 16), not pass the pressure to the team.
Scope protection is the 'shield' half of the in-sprint PM role (Tool 16).
It defends the Sprint Goal and backlog (Tools 05, 06) from erosion.
Constant scope change makes velocity (Tool 03) meaningless; protected scope keeps it useful.
Honest trade-offs connect to the influence and negotiation skills of Module 6.
Imagine a stakeholder asks you mid-sprint to 'just also fit in' a new request. Write the response that neither flatly refuses nor silently absorbs it — make the trade-off explicit.
Your response should name what committed work would have to drop, and hand the priority decision back to the requester.
If your reframed answer turns a yes/no demand into 'yes, but here's the cost — you choose,' you've found the move that protects the sprint without stonewalling the business.