A stakeholder says the new request is not a change, it is just a clarification. How do you handle that?
5 min readUpdated 2026-08-15
0
Answer
Short answer
Stop arguing about the label and test the request against the accepted criteria: if the behaviour or the effort changes, it is a change whatever it is called. Hand the product owner a delta and options rather than a refusal, and keep a log so a fortnight of small clarifications stays visible.
Was this answer helpful?
Likely follow-ups
→The request turns out to be a rule you missed during elicitation. Does that change who absorbs the cost?
→Where does the running log of these requests live, and who reads it?
→The stakeholder goes directly to a developer next time. How do you respond?
→How would this conversation differ under a fixed-price supplier contract?
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.
Loading diagram…
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.