Why this matters: this is the mechanism that actually eats our sprints. Everything else in these notes is important, but if you fix only one behaviour, fix this one. The full diagnosis is in Why We Miss Deadlines.
The moment where it goes wrong
A Story was agreed: export invoice as PDF, 5 points, acceptance criteria written.
The developer demos it on day six. The stakeholder is happy, and then says, perfectly reasonably:
“Nice. Can we also export to Excel and CSV? And can it email the invoice directly to the customer?”
What happens next decides whether your sprint survives.
What we usually do: add three tasks under the same Story. Nobody records that the Story changed. The board still says 5 points. At the end of the sprint the Story is incomplete, it carries over, and the retro concludes that our estimates are unreliable.
Our estimate was never the problem. We estimated A and then delivered A+B+C+D. That is not an estimation failure, it is a scope failure, and the two need completely different fixes, as laid out in Estimation and Story Points.
What should happen: the Product Owner creates three new backlog items, prioritises them, and the current Story finishes as agreed. If Excel export genuinely cannot wait, the PO explicitly removes something else from the sprint to make room, out loud, in front of the team.
Agile does not mean unlimited scope changes
This is the misconception at the centre of the whole problem.
Agile means: we welcome learning, and we can change future priorities quickly.
It does not mean: every stakeholder request immediately enters whatever is currently being built.
The Scrum Guide is precise about this. During a sprint, no changes are made that would endanger the Sprint Goal, and scope may be clarified and renegotiated with the Product Owner as more is learned. Both halves of that sentence matter. The sprint is adaptable, but it has a spine, and the spine is the goal, which is why Sprint Planning and Refinement insists on writing one.
Classify before you react
Not all feedback is the same thing. Here is the table. Use it literally, out loud, when feedback arrives.
| What the feedback actually is | How to recognise it | What to do |
|---|---|---|
| Defect | The implementation does not match the agreed Acceptance Criteria | Fix it inside the current Story. This is not new scope, it is unfinished work. |
| Clarification | The intended behaviour was implied by the criteria but was misread | Correct it in the current Story, and fix the criterion wording so the next person does not hit it. |
| New scope | A capability that nobody agreed to, and that the criteria do not mention | New backlog item. Prioritise and schedule it. Do not touch the current Story. |
| Requirement change | The business need itself has genuinely changed, so the agreed behaviour is now wrong | Product Owner decides: stop the work, redefine the Story, or finish it and schedule the change. A real decision, made deliberately. |
| Urgent production issue | Customers are affected right now | Take it, and explicitly remove comparable work from the sprint. Never add it on top. |
| Nice idea from the demo | “It would be good if it also did…” | Backlog item. Prioritise later. Thank them, because this is how good products are found. |
The single test that sorts most cases:
Is this required to satisfy what we already agreed, or is it something additional?
If it is required to satisfy the agreement, it belongs in the Story. If it is additional, it is a new item. There is no third option, and “it is only a small addition” is not a category.
The policy sentence
I would print this and put it where the team and the stakeholders can both see it:
A Story may change during development when we discover what is genuinely necessary to satisfy its agreed objective and acceptance criteria. New capabilities discovered through feedback become new backlog items rather than silently expanding the current Story. Any material change during a sprint is discussed with the Product Owner and the developers against the Sprint Goal.
One paragraph. It removes most uncontrolled scope growth, not because it is clever, but because it makes the decision explicit instead of automatic.
Urgency: how the trade works
When something urgent truly must enter a running sprint, the arithmetic must be visible.
Wrong:
Sprint committed: 25 points
Urgent arrives: +8 points
Expectation: "somehow finish 33"
That is not a plan, it is a wish transferred onto the developers, and it always ends the same way.
Right:
Sprint committed: 25 points
Urgent arrives: +8 points
PO removes: -8 points of lower priority work
Sprint remains: 25 points, with a different mix
The second version is a real decision with a visible cost. Somebody who wants the urgent thing has to accept that something else moves. That is not obstruction, that is what prioritisation is. A Product Owner who never removes anything is not prioritising, they are queueing.
How to say no without sounding obstructive
The fear of saying no is a large part of why teams absorb scope. But nobody is actually saying no. They are saying “not silently, and not for free”.
Useful sentences:
“Good idea. That is new behaviour we did not agree on, so let me put it in the backlog and we will size it properly rather than squeeze it in badly.”
“We can do that this sprint if it matters more than the reporting Story. Which one do you want first?”
“That is a different Story, and honestly it deserves its own acceptance criteria. If we bolt it on now we will not test it properly.”
“The acceptance criteria say PDF only, and that is what we agreed. Excel is absolutely worth doing, it just is not this Story.”
Notice that none of these refuse the work. They refuse doing it invisibly. Stakeholders are almost always fine with this once they trust that items in the backlog actually get built. Where the conversation goes badly, it is usually because the backlog has historically been a graveyard, and that is a trust problem to fix separately.
Write down what is out of scope
The cheapest prevention available: every Story carries an explicit “out of scope” line, as shown in Acceptance Criteria.
Out of scope: Excel export, CSV export, emailing the invoice, bulk export.
When those things come up at the demo, the conversation is already settled. You are not arguing about whether it was supposed to be included, you are agreeing on when it gets built. This one habit converts the most common mid sprint argument into a two sentence exchange.
Measure how much scope gets added
If you only track what you completed, scope growth stays invisible and gets misdiagnosed as poor estimation every time.
Track two numbers per sprint:
- Points committed at planning
- Points added after the sprint started
Azure DevOps sprint burndown shows mid sprint scope increases directly, and the setup for tracking it is in Azure DevOps Setup. Bring both numbers to the retrospective.
The reason this number matters more than it looks: it converts a subjective argument into a fact. “The team is slow” and “requirements keep changing” are opinions that cannot be resolved. “We committed 25 points and added 14 points mid sprint, three sprints in a row” is a fact, and facts can be acted on. In most struggling teams I have seen, this one number explains the majority of the delay, and nobody was measuring it.
Keep the testing honest too
There is a quieter version of this problem that nobody notices.
Feedback arrives, the developer changes the behaviour, and the Acceptance Criteria are never updated. Now the written criteria describe something the product no longer does, the test cases test the old behaviour or were never written, and in six months the only record of the real behaviour is the code.
So whenever feedback is accepted into a Story:
- Update the acceptance criteria to match what was actually agreed.
- Update or add the test case.
- If the change affects an existing feature, update its entry in Feature Inventory and Ownership.
If that sounds like overhead, compare it to the cost of the alternative, which is the situation described in Test Case Strategy: a large product where nobody can say what the correct behaviour is.
The shortest version
flowchart TD
A["Feedback arrives"]
B{"Is it required to satisfy what we already agreed?"}
C["YES"]
D["NO"]
E["Fix in this Story"]
F["Create a new backlog item"]
G{"Is it urgent enough to enter this sprint?"}
H["YES"]
I["NO"]
J["PO removes equivalent work"]
K["Prioritise for later"]
A --> B
B --> C
B --> D
C --> E
D --> F
F --> G
G --> H
G --> I
H --> J
I --> K
Four boxes. Following them consistently will do more for your delivery dates than any estimation technique in Estimation and Story Points.