A stakeholder says the new request is not a change, it is just a clarification. How do you handle that?

Why they are arguing about the word

The label is not idle vocabulary. "Clarification" means free, invisible and inside the current date; "change" means a conversation with a product owner, possibly a trade-off, possibly a slipped commitment and, on a contract, an invoice. The stakeholder is not being dishonest by reaching for the softer word — they are making the claim that gets their need met with the least friction, and often they genuinely believe the requirement was always implied.

Which means you should not fight over the word at all. Arguing terminology puts you in the role of gatekeeper, makes the discussion about process rather than about the business, and you will lose even when you win. What decides it is a test anybody can apply: read the accepted acceptance criteria out loud, and ask which of them already covers the requested behaviour. If one does, it is a clarification and you answer it in five minutes. If none does, something new is being asked for, and the label follows from that rather than from who is more senior in the room.

Three things wear the same disguise

The test above sorts requests into three piles, and they are handled differently.

A true clarification is a question about something already agreed but ambiguously worded. The behaviour does not change, the estimate does not change, and the right output is a recorded interpretation so the same question is not asked again in three weeks.

An omission is a rule that was always true and that you did not find. The customer is not asking for anything new; your analysis was incomplete. Own that plainly, because pretending otherwise costs you credibility you will need later. Owning it does not make the work free, though — the build still has to absorb it, and the sprint commitment or the date still has to reflect it. The honest framing is "you are right, this was always the rule and I missed it, and it is two days of work we had not planned; here is what that does to Friday."

A change is new or altered behaviour. Something about the business intent has moved, or a decision that was made one way is being remade. These are legitimate and normal; they simply have to be seen.

flowchart TD
  A[Request arrives mid sprint] --> B{Covered by accepted criteria}
  B -- yes --> C[Answer and record the interpretation]
  B -- no --> D{Was the rule always true and missed}
  D -- yes --> E[Log as analysis gap and re-estimate]
  D -- no --> F[Log as change with cost and options]
  E --> G[Product owner decides absorb swap or defer]
  F --> G

Both of the lower branches converge on the same person, which is the point worth noticing: an omission and a change differ in whose fault they are, not in who decides what happens next.

Give the owner a delta, not a verdict

You do not own scope, and behaving as though you do is the fastest way to be routed around. What you own is the delta: what specifically changes, in criteria and in effort, and what the options are. Put it in one short message.

That request needs a new rule for part-month joiners, which is not in the criteria we agreed on 8 May. It is about a day and a half including the test cases. Three options: it replaces the supplier-statement export in this sprint, it goes into the next sprint and the pilot date holds, or we take it now and the pilot moves to the 19th. My recommendation is the second. Can you confirm by Thursday?

That phrasing does four things a refusal cannot. It cites the agreement rather than an opinion, it prices the request, it makes the date consequence explicit, and it leaves the decision with the person entitled to make it. The stakeholder asking is rarely the person who has to trade something away, and putting the two of them in contact resolves most of these without you being in the middle.

The aggregate is what actually kills the sprint

No single one of these is worth a fight, and that is precisely the mechanism by which they do damage. Half a day here and a day there, seven times over, is the missed sprint that gets discussed at retro as a velocity problem. So keep a plain list — date, requester, request, classification, cost — and bring it to sprint review or the weekly steering call as a number rather than as a grievance. Eleven requests this sprint, of which four were true clarifications costing nothing and seven were changes or rules missed at elicitation, totalling six days against a sprint of forty, is a fact people can act on; "we keep getting interrupted" is a complaint they cannot.

The log also changes future behaviour without any confrontation, because a requester who can see their own name against six entries starts batching and prioritising on their own.

Do not win this one at the cost of the relationship

The tone that fails is procedural triumph: the analyst who produces the signed baseline and explains that the request is out of scope. It is technically correct and it teaches the business to stop telling you things, which costs you far more than the day and a half. Say yes to the need and neutral about the mechanism — the request is reasonable, here is what it displaces, you choose. Scope control done well feels to the stakeholder like getting help with a trade-off, not like being caught out.