Managing Requirements Changes Mid-Sprint

On the eighth day of a ten-day sprint, the head of operations stops by the team's standup. The reporting story — the one two engineers are halfway through — looks great, she says. Could it also export to CSV? Finance has been pasting numbers by hand and it's killing them. It's just a button, right?

It is not just a button, and everyone in the room knows it. But "no" feels obstructive, "yes" quietly blows the sprint, and "let me get back to you" is how a team earns a reputation for being slow. The reflex most teams reach for is a rule — we don't take changes mid-sprint — and rules like that are how good teams end up shipping the wrong thing on time. The problem with a mid-sprint change is not that it arrived. It's that it arrives as a feeling ("just a button") and gets answered as a feeling ("sure" or "no"), when what it needs is to be turned into a small, boring artifact that makes the real cost visible. This piece is about that artifact and the two-minute intake that produces it.

(Developed example — a simple scenario.) We'll follow the export-to-CSV request all the way to a decision, using the exact note the team wrote to get there.

The first question isn't yes or no — it's new or restated

Before anyone estimates anything, there is a discovery move that decides which conversation you're even having. Ask one intake question: "Is this a new requirement, or a restatement of one we already had?" The answer sorts every mid-sprint change into three bins, and only one of them is actually a change.

Run the CSV request through it. You ask the head of operations: when we scoped this reporting story, was exporting the data something Finance needed then, or is this new information since? She thinks about it and admits Finance always exported reports — from the old system, every month. That single answer is diagnostic. This isn't a new requirement discovered mid-flight; it's an old requirement that never made it into the story because nobody asked Finance how they used reports, only what reports they wanted. The export was knowable at planning. It was skipped in discovery.

That distinction matters because the three bins get handled differently. A genuinely new requirement (the market moved, a regulation dropped) is legitimate work that has to compete for space. A restated requirement — one that was always true and simply not elicited — is a discovery gap, and the fix is upstream, not mid-sprint heroics. And a third bin, the restated-and-contradictory change, is really two stakeholders who never agreed; that's a different problem, worked through in handling conflicting requirements, not a scoping call. Naming the bin out loud also does something political: it moves the conversation from "will you do me this favor" to "here's what we missed and here's what it costs to fix now."

The test you can run: for the next change someone hands you, ask whether the need existed at planning and you failed to elicit it, or genuinely arose after. If the honest answer is "it existed and we didn't ask," log it as a discovery miss — because a team that takes three of those a sprint doesn't have a change-control problem, it has an intake problem, and no amount of sprint discipline will fix a leak that starts before the sprint does.

What the change actually costs — and where the cost hides

The reason "just a button" is dangerous is that the button is the cheapest part. The expensive part is invisible in the request and only appears when you decompose it.

Adding CSV export to a story in progress isn't additive; it's disruptive in a specific, mechanical way. The two engineers are holding a mental model of the reporting feature — the query shape, the render path, the edge cases they've already found. A new requirement mid-story forces a context switch: they drop that model, load a new one (file streaming, column escaping, the empty-result case, large-export timeouts), and when they return, they rebuild the first model from cold. The switch is paid twice, and neither payment shows up as a line item. Worse, a change to a story already in progress usually touches its acceptance criteria — and the moment a change edits acceptance criteria on an in-progress story, you are not tweaking, you are re-planning. The story you estimated no longer exists; you now have a different, larger story wearing the same ticket number.

That is the line worth internalizing, because it's observable. The test: look at where the change lands. If it only adds a new story to the backlog, it's cheap to defer and cheap to absorb. If it edits the acceptance criteria of something a person is mid-way through building, treat it as a re-plan and price it as one — the sunk mental context is part of the bill, not a rounding error.

Turn the feeling into a note, then read the note

Here is the artifact. When a change survives the intake question and is real enough to consider, whoever's closest to the work writes a change-impact note — five lines, five minutes, before anyone argues. For the CSV request it read like this:

• Change: Add "Export to CSV" to the in-progress Monthly Reporting story.

• What it touches: one new acceptance criterion on an in-progress story (so: a re-plan, not a tweak); the report data layer; one new UI control; a new edge case (empty result set) and a non-trivial one (exports over ~50k rows time out on the current query).

• Cost: ~3 points — roughly a third of this two-person team's remaining sprint capacity.

• What it displaces: the "email digest" story (3 points), which is the only thing that fits in the hole it makes.

• In or out, this sprint: out — deferred to next sprint's top of backlog, with a same-day manual export script handed to Finance as a bridge.

Notice what the note did. It converted "it's just a button" into "it's a third of our remaining capacity and it costs us the email digest," and it surfaced the 50k-row timeout — a genuine technical risk nobody would have seen from the hallway. The decision almost makes itself once the note exists: the export is real and worth doing, but it is not more urgent than the digest, and doing it properly (including the timeout) is not a mid-sprint patch. So it goes to the top of the next backlog, and Finance gets an unglamorous stopgap this week so the actual pain — hand-pasting — stops now. That stopgap is the tell of a mature answer: you can serve the underlying need without deforming the sprint. The note gets attached to the story so the decision is traceable later, which is the lightweight cousin of a full requirements traceability matrix — you want to know, three months on, why export shipped a sprint late and on purpose.

The test: for your next change, write the five lines before the discussion, not after. If you cannot fill in "what it displaces," you have not found the cost yet — every mid-sprint yes displaces something, and a note that can't name the victim is hiding the bill, not paying it.

Absorb, defer, or swap — and what each one signs you up for

Once the note exists, a real change has exactly three honest destinations. The failure mode is pretending there's a fourth — "just squeeze it in" — which is absorb-now with the cost deleted from the story instead of the sprint.

Option	What you do	The cost you take on	The signal that it's the right call
Absorb now	Add it to the current sprint, keep the goal	Silently drops slack, risks the sprint goal, hides the trade in overtime	The change is small, touches no in-progress acceptance criteria, and fits in existing slack
Defer to next sprint	Top of the next backlog; offer a manual bridge now	A short wait; a stopgap you have to build and then throw away	The need is real but not time-critical, and a cheap bridge relieves the pain today
Swap out	Take it in now, explicitly pull something else out	A visible, agreed loss of the displaced story this sprint	The change genuinely outranks something already in the sprint, and the owner signs off on the trade

The rule that keeps this honest: there is no such thing as absorbing a change without displacing something — the only question is whether the displacement is written down or paid in erosion. Swap-out is not the harsh option; it's the honest version of absorb-now, because it names what you gave up. When priorities are genuinely contested, run the swap through an explicit ranking method like MoSCoW prioritization so the trade is a decision the whole room made, not a favor one engineer did in the dark.

The test: name your change's destination out loud before you act — absorb, defer, or swap — and if the honest answer is "absorb," point to the slack it fits in. If you can't point to the slack, you're not absorbing, you're swapping without telling anyone, and the thing you're swapping out is your sprint goal.

When taking the change mid-sprint is the right call

The whole apparatus above biases toward defer, and that bias is correct most of the time — but not always, and treating "never mid-sprint" as law is its own failure. There are changes you take immediately, no note required, and they share a property: the cost of waiting exceeds the cost of the disruption. A production incident, a security vulnerability with an active exploit, a compliance deadline that lands inside the sprint window, a change that makes the in-flight story demonstrably wrong to ship — these outrank the sprint goal because shipping on schedule with them unaddressed is worse than shipping late.

The export request fails this test cleanly: hand-pasting is painful but not damaging, and a manual bridge neutralizes it. But flip one detail — suppose Finance's month-end close is legally due in three days and the export is the only path to it. Now the deadline is external and immovable, the reversal cost is high, and defer stops being responsible. You'd swap, pull the digest, and take the change in — and you'd still write the note, because the note is what lets you defend the swap to the person who wanted the digest. The exception isn't "sometimes skip the process." It's "sometimes the note's own numbers point at swap now instead of defer."

The test: before you invoke the emergency lane, state the external force and the cost of waiting a week. "The regulator's deadline is Thursday" qualifies. "The stakeholder is anxious" does not — anxiety is real, but it's relieved by the bridge and the note, not by detonating the sprint.

Protecting flow without becoming the department of no

A team that runs this well is not a team that refuses changes. It's a team where changes stop being ambushes because the response is legible: every request gets the intake question, real ones get a note, the note names the trade, and the trade gets decided by the person who owns the priority — not absorbed in silence by whoever was too polite to push back. That legibility is what lets you say "not this sprint" without sounding obstructive, because you're not saying no to the need, you're showing the math and offering the bridge. It's also what makes sign-off mean something instead of ritual — the sign-off that isn't theater is one where the approver saw the displaced story by name.

So the change to make this week is small and specific. The next time someone brings you a mid-sprint "can it also…", don't answer it and don't refuse it. Ask the one intake question — new, or restated? Then, if it's real, write the five-line note before the conversation, and let the note's own "what it displaces" line make the call. You will defer most of them with a clear conscience and a stopgap, absorb the genuinely small ones against real slack, and swap for the rare change whose numbers demand it — and in every case you'll have an artifact that tells the next person why. The teams that survive changing requirements aren't the ones that hold the line hardest or bend the fastest. They're the ones who made the cost of each change visible enough that the right answer was obvious to everyone in the room, including the person who asked.