Change requests in the middle of a Sprint

On Wednesday of the second week, a senior stakeholder sends a message to a Developer: "Can we squeeze in one small thing? The regional director wants the report to have a new column." It is small, and the director is senior. By Friday, three more small things have arrived, the Sprint Goal is at risk, and nobody can say which request caused it. Scrum has a clear answer to this, and the answer is less rigid than it sounds.

The principle

Scrum is built to welcome change, and the Agile Manifesto states it directly: welcome changing requirements, even late in development. The framework does this by making the Product Backlog easy to change and by keeping each Sprint short, not by letting scope drift inside a Sprint.

The Scrum Guide's rules for a Sprint say it plainly. No changes are made that would endanger the Sprint Goal. Quality does not decrease. The Product Backlog is refined as needed. Scope may be clarified and renegotiated with the Product Owner as more is learned. Read these as one thought: the goal is protected, and everything below it can move by agreement.

The SBOK® Guide says the same in firmer language. The scope of a Sprint cannot be changed once it begins. The Product Owner, after consulting stakeholders, decides whether a change can wait for the next Sprint or is so urgent that the current Sprint should end. If the Sprint's results would be worthless without the change, the Sprint should be terminated, and otherwise the change goes into a later Sprint. The Scrum Guide's equivalent is that a Sprint could be cancelled if the Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel it.

Why not just add it

The SBOK explains the reasoning, and it holds up. In traditional management, changes can be requested at any time, and that can cause confusion, reduce motivation through discontinuity and leave the team feeling that nothing ever gets finished. Locking the Sprint's scope lets the team plan and manage its effort efficiently, and means the business sees finished work at the end of every Sprint.

There is also a plain arithmetic reason. A team's capacity is fixed. Adding one thing means removing another, or lowering quality. Declining to decide that explicitly is still a decision, and usually the worst one.

Four responses, in order of preference

When a request arrives, a sensible order of thought is:

1. Put it on the Product Backlog. The Product Owner records it, orders it relative to other items, and tells the requester where it sits. In most cases, this is the end of it for the current Sprint.
2. Check whether it serves the Sprint Goal. If it does, and it is small, the Developers and the Product Owner can negotiate: what comes out to make room? That is scope renegotiation, which the Guide allows.
3. Check whether it threatens the goal. If it is urgent enough that the goal would be pointless without it, the Product Owner decides whether to change course. The Guide gives only the Product Owner the authority to cancel.
4. Cancel and re-plan. Rare, and costly. It discards a Sprint of rhythm and learning.

For the Developers, the working rule is: nothing new goes into the Sprint without the Product Owner agreeing, and nothing agreed goes in without something leaving or the goal being revisited.

The SBOK adds a single exception for the other direction. If the team finds it has heavily overestimated the effort and has spare capacity, it can ask the Product Owner which additional stories to bring into the current Sprint. That is the team using its own slack, not an outsider adding load.

What the Scrum Master does

Protecting the Sprint is the Scrum Master's business, as the Guide's description of the role says: ensuring that events are productive and helping the Scrum Team focus on high-value Increments that meet the Definition of Done. In practice:

• Redirect requests to the Product Owner, politely and consistently.
• Help the Product Owner explain to the requester what happens next.
• Notice when the same kind of request keeps arriving, because that is a sign the Product Backlog or the stakeholders' expectations need attention, and a topic for the Retrospective.
• Back the Developers when they say no.

A worked example

An invented case. A mid-Sprint request arrives from a regulator: a new field must be captured on a booking form. The date is six weeks away.

• The Product Owner records it on the Product Backlog at once and confirms the deadline. The request is not optional, so it goes high in the order.
• The Sprint Goal is "a member can book a room". The new field is unrelated to the goal, and the current Sprint is full. It is not added now.
• At the next backlog refinement, the Product Owner and Developers size it. It is small.
• It is planned in the next Sprint, well inside the deadline. The regulator's date is met, and the current Sprint finishes its goal.

Now change one fact: the regulator's date is in five days. The Product Owner decides this is urgent. The Developers agree to do it in the current Sprint and the Product Owner agrees to move one lower-priority story out. The goal is intact, scope was renegotiated, and the Sprint Review reports both.

Common mistakes

• Saying yes to be helpful. An unexamined yes borrows from the Sprint Goal.
• Saying no with no alternative. A refusal that offers no path ("it will be considered at the next planning") makes people go around the process.
• Taking requests directly. Developers who accept work from anyone make the Product Owner's ordering meaningless.
• Treating every request as an emergency. Most are not. Ask what happens if it waits.
• Cancelling too readily. The Guide reserves it for an obsolete goal.
• Hiding the trade-off. The Product Owner should say what was displaced.

How to practise it

In the simulator, a change request arrives in the middle of a Sprint at the backlog refinement step. The current Sprint stays as committed, and you decide whether to add the request to a future Sprint, reject it or try to squeeze it into the current one.