Change requests mid-sprint: how should a PO handle it?

A new request in the middle of the sprint

This is an illustrative situation. You are the PO of an online bookshop. A two-week sprint is halfway through, and the Sprint Goal is: “Customers can pay with an e-wallet inside the app.” The team is integrating the payment gateway, the tester is writing test cases, and everything is on plan.

Then the marketing lead messages you: “Can you add a countdown timer and auto-apply the discount code for the end-of-month sale? The campaign starts before your sprint ends.” Right after that, an engineer posts in the team chat: “The book detail page is showing broken images on some phones, customers are complaining.”

Two requests in one morning, both sounding urgent. You do not want to disappoint marketing, and you do not want the team to drop the payment work halfway. This article walks through how to decide: which changes belong in the sprint, which should wait, what to tell the requester and what to tell the team.

Why are mid-sprint changes hard for new POs?

Mid-sprint changes are not hard because a process is missing. They are hard because you stand between two groups who both have a point.

• The requester has a real reason: a campaign, a client, a number their manager needs. From where they sit, “just a little extra” looks small.
• The team also has a real reason: they committed to a goal in sprint planning, they have work in progress, and every change of direction costs time to get back into flow.
• You have nothing to compare against yet. Early in the role, it is hard to tell which requests deserve a change of plan and which only feel urgent.
• You may misread your own authority. Many new POs think they can push work into the sprint themselves. The Scrum Guide 2020 calls the Sprint Backlog a plan “by and for the Developers”. Developers here means everyone in the team who builds the product, not only engineers. The PO negotiates scope with the Developers rather than ordering extra work.

There is an opposite misunderstanding too: once the sprint is planned, nothing may be touched. If you refuse every change, the team may deliver exactly the plan but ship something that no longer fits the situation. The sensible approach sits between those extremes, and it turns on one question: is the Sprint Goal affected?

What does the Scrum Guide say about changes during a sprint?

The Scrum Guide 2020 has a few short lines worth remembering in its section on the sprint. In summary:

• No changes are made that would endanger the Sprint Goal.
• Quality does not decrease.
• Scope may be clarified and renegotiated with the Product Owner as more is learned.
• A sprint could be cancelled if the Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel it.

In other words, the Sprint Goal is what you protect, while the specific list of work to reach it is allowed to change. Scrum.org's article on the myth that the Sprint Backlog cannot change takes the same line: the Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.

Mountain Goat Software adds a useful distinction: adding a task to finish an existing story is a plan update, while adding a new product backlog item to the sprint is a different matter. New functionality usually belongs in the product backlog, and if it affects the sprint, the PO and the Developers should discuss the trade-off explicitly.

The rest of this article is this article's own approach, built on those three ideas. It is not a rule from the Scrum Guide.

How to handle a mid-sprint change request: four steps

First, set one kind of question aside: clarifying a story already in progress, such as an engineer asking where a button goes or how an error case should behave. That is clarifying scope, not a new request. Answer it straight away; it does not go through the steps below.

For genuinely new requests, a simple approach is to run every case along the same path, even small ones. No meeting is needed. Often it is a few messages and five minutes with the team.

Step 1 is the same as handling any feature request: find the problem behind the proposed solution. The most important question here is “What happens if this ships in the next sprint?”. The answer tells you whether the deadline is real or just a wish.

Step 2 is the one new POs tend to skip. Do not estimate on the team's behalf. Ask one or two people on the team: how big is this, does it touch the work for the Sprint Goal, is there any risk to quality. Five minutes with the right people keeps you from promising something the team cannot deliver.

To choose a response at step 3, you can use the filter below. A “yes” moves you forward. A “no” sends you to the action beside it. The first question is for severe incidents. How that branch is handled is this article's view; the Scrum Guide has no specific rule on incidents.

• Prioritising the backlog when everything is urgent

Swap or add: what is the difference?

Adding means the sprint keeps all its existing work and takes on the new item as well. Swapping means that when the new work comes in, work of similar size goes out.

Adding sounds nicer to the requester, but it assumes the team has spare time. When sprint planning already filled the sprint to the team's capacity, adding easily means something else will not get done. Nobody has said what yet. Swapping makes everyone say it up front.

Cancelling a sprint is a heavy choice. Save it for when the Sprint Goal is truly obsolete, for example when the company decides to drop the feature the sprint is building. An urgent but small request is not a reason to cancel.

• Sprint planning: what should a PO prepare

Common types of change and how to respond

Not every change is the same. The table groups the kinds of change a PO may meet mid-sprint, with a suggested response. These are this article's suggestions; your team may have its own conventions.

The “Clarifying a story in progress” row is the one to remember. Many mid-sprint questions are simply clarifying the scope of a story that is already there. That is normal, and the Scrum Guide clearly allows it. Do not treat every question from the team as a change to be handled like a new request.

• Acceptance criteria: writing them so they can be tested

Example: an end-of-month sale in the middle of a payments sprint

Back to the online bookshop. This is an illustrative conversation that follows the four steps above.

Step 2: the PO asks the team. An engineer says the countdown lives only on the home page, takes about a day, and does not touch payments. Auto-apply means changing the cart and checkout flow, exactly where the team is integrating the e-wallet. Doing both at once would raise the risk to the Sprint Goal.

Step 3: the PO runs each part through the filter. Both parts can wait for clarification, and the problem is clear.

• The countdown has a real deadline inside the sprint. The team confirms it can be done while the Sprint Goal is still met. The team agrees to move the “new releases page” story, similar in size and not part of the Sprint Goal, back to the product backlog. Result: a swap.
• Auto-apply stops at the third question. Customers can still type the code, so there is no real deadline that forces it into this sprint. It goes into the product backlog for the next sprint planning, with a banner showing the code as the workaround. Even with a real deadline, it would stop at the fourth question, because it touches the payment work for the Sprint Goal.

Step 4: the PO replies to marketing. The countdown will be live before the campaign starts, auto-apply will be reviewed at the next sprint planning, and meanwhile the banner shows the code clearly so customers can type it easily. The PO also tells whoever asked for the new releases page that their item has moved back one sprint, and why.

And the broken images? The engineer checks and finds the bug only appears on one older phone model, and the images still load after scrolling. It can wait and has no real deadline inside the sprint, so it goes into the product backlog with high priority for the next sprint. If the bug stopped customers from placing orders, it would turn off at the very first question: the whole team decides to fix it now, and if the fix endangers the Sprint Goal, they renegotiate scope together.

What do you say to the requester and to the team?

What the requester most needs to hear is not “yes” or “no”, but the cost and the timeline. A good reply can have four parts: restate the problem in their words, say what can be done this sprint, say what will slip in exchange, and give a date for the rest.

When the requester is your manager or someone with more authority than you, ask the team first, then offer only options the team has confirmed it can do while still meeting the Sprint Goal. Let your manager choose between them, instead of refusing on your own. For example: “The team can deliver the countdown this sprint if the new releases page moves to next sprint. Auto-apply touches the payment work in progress, so the team suggests looking at it next sprint. Would you like that swap, or keep the sprint as it is and do the countdown next sprint, accepting that it will miss the first day of the campaign?”

With the team, do not arrive with a decision already made. Bring the problem, the real deadline and a question: “Is there a way to do the most urgent part while still meeting the Sprint Goal?”. People on the team may see ways to shrink the work that a PO would not think of. After a swap, update the sprint board straight away so nobody keeps working on the item that moved out.

If a change does go into the sprint, tell the team who asked for it and why. Teams accept a change of plan more easily when they understand the reason, and less easily when new items simply appear on the board with no explanation.

• Saying no to stakeholders without losing goodwill

What do frequent mid-sprint changes cost?

A single change can be entirely reasonable. The problem starts when change becomes a habit. The cost is often not only in the work that was added, but also in things that are harder to see:

• Unfinished work. Every change of direction leaves something half done. The sprint can end with several items half finished and nothing shippable.
• Time to get back into flow. People on the team stop what they were thinking about, read the new request, and later find their way back to the old work.
• Trust in the plan. If every sprint plan is changed halfway through, stakeholders stop believing the plan and the team stops trying to commit.
• Quality. When new work is forced in, testing and error handling are the easiest parts to cut, which is exactly what the Scrum Guide says must not decrease.

A simple way to measure this is a change log. Every mid-sprint change gets one line. At the end of the sprint, bring the log to the retrospective and ask: which changes truly could not wait, and which could have been seen at sprint planning. If the same department keeps sending urgent requests, they may need an earlier invitation to backlog refinement or sprint planning.

If urgent changes are so frequent that every sprint gets broken, that is a signal to talk with the team about sprint length or about how urgent work is taken in. This article does not suggest a specific threshold, because it depends on the team. The change log gives you real numbers from your own team to discuss.

Message and change log templates

Both templates are for step 4. Copy them and adjust to the way your team talks.

I've talked with the team about [request name].
My understanding is that the problem is [restate the problem in their words].
This sprint, the team can deliver [the part we can do], ready by [date].
To make room for it, the team is moving [work that slips] to the next sprint.
[The remaining part] will be reviewed at sprint planning on [date].
In the meantime, you could [workaround].
If [something changes], let me know and we'll look at it sooner.

Sprint: [sprint name or number]
Sprint Goal: [goal]

Date: [date]
Requested by: [name, team]
Request: [one-sentence description]
Why it could not wait: [incident / legal deadline / dated commitment / other]
Impact on the Sprint Goal: [none / yes, describe]
Decision: [wait for next sprint / swap / handle incident now / cancel sprint]
Work moved out of the sprint: [item name or none]
Decided by: [PO and team]
Requester informed: [yes / not yet, date]

The change log needs no special tool. A shared notes page or a comment column on the sprint board is enough, as long as the whole team can read it and it comes to the retrospective.

Common mistakes with mid-sprint changes

• Accepting first and asking the team later. You promise a date the team has not seen, then have to go back to apologise or push the team into overtime.
• Adding without taking anything out. The sprint is already full, so adding just means something else quietly fails to finish by the end of the sprint.
• Choosing on your own what moves out. People on the team know which items are half done and which are easy to pause. Choose together.
• Treating every clarifying question as a change. Clarifying the scope of a story in progress is normal sprint work. Just answer it quickly.
• Refusing every change to protect the plan. The Sprint Goal is what you protect. The list of work to reach it can change as the team learns.
• Cancelling a sprint over an urgent but small request. Cancelling is for when the goal is obsolete, not for something you can swap.
• Not telling the person whose work slipped. Whoever owned the item that moved out also needs the reason and the new date.

Summary

• Apart from incidents that need action now, the key question for any mid-sprint change is: does it endanger the Sprint Goal? The Scrum Guide 2020 does not allow changes that endanger the goal, but allows scope to be clarified and renegotiated with the PO.
• Answer clarifying questions about a story in progress directly. New requests go through four steps: log and clarify, check the impact with the team, choose a response, reply and record.
• No real deadline: put it in the product backlog for the next sprint. Truly urgent and not touching the goal: swap, do not add.
• Only the PO can cancel a sprint, and it should be used only when the Sprint Goal is obsolete.
• Keep a change log every sprint and bring it to the retrospective to see the cost of frequent change.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

• Get new articles by email

Frequently asked questions

Can you change the scope of a sprint that is already running?

Yes, scope may be clarified and renegotiated with the PO as the team learns more. But the Scrum Guide 2020 allows no changes that would endanger the Sprint Goal.

Who can cancel a sprint?

According to the Scrum Guide 2020, only the Product Owner has the authority to cancel a sprint, and the case it describes is when the Sprint Goal becomes obsolete, for example when a business shift makes the goal meaningless.

What should a PO say when the boss asks for something urgent mid-sprint?

Ask the team first, then offer only options the team has confirmed it can do while still meeting the Sprint Goal, with the work that would slip. Let the boss choose between that swap and doing it next sprint.

Sources to check

• Scrum Guide 2020: The Sprint
• Scrum.org: Myth 2, The Sprint Backlog can't change during the Sprint
• Mountain Goat Software: Sprint Backlog

Related articles

• What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
• What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
• Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
• How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.