How to handle changing requirements

Published 22 October 2026

Requirements change on almost every project, so the goal is not to stop them changing but to handle each change as a decision: find out what it really is, decide when it happens — now, next sprint, next release — with its cost in view, and update the requirement instead of building around it. Below are why requirements keep changing, what to do when a change arrives mid-sprint, after sign-off, or every week, how to handle a client who keeps changing their mind, and the sentences that help.

There’s a famous military saying, attributed to Helmut von Moltke: ‘No battle plan survives contact with the enemy’. In the same vein, I do not think it’s possible to make a spec that will not have to be changed

— accepted answer, Software Engineering Stack Exchange, 2012

Changing requirements are normal

“In reality, requirements are never fixed,” runs another accepted answer (Stack Exchange, 2018). The Agile Manifesto builds on it: “Welcome changing requirements, even late in development” (Agile Manifesto principles). One commenter, writing from a developer’s and architect’s side: “Trying to avoid & resist churn never seems to work. My life is better when I plan for churn” (r/agile, 2022).

Welcoming change does not mean taking every change at once. The question is never “can this change?” but “when, and what does it cost?” The process that answers it is requirements change management; this page is about the day-to-day of using it.

Why requirements keep changing

• People learn what they want by seeing it. “When you actually get the customer to think about the UI or get them to look at one then inevitably the domain model gets adjusted in response” (Hacker News, 2023). The question “Manager keeps changing requirement specification after every demo” got the answer: “Sounds like the real world. This happens all the time, everywhere” (Stack Exchange, 2011).
• The real problem was never found. One commenter’s diagnosis: “your understanding of business requirements is changing even after the sprint is started, because you never identified the real problem” (r/ProductManagement, 2024).
• The business changes: a new rule, a new customer, a competitor, a law.
• Several people can ask, and nobody says no. Then each request is small, and the total is not.

The first two are worth spotting, because they call for a different response than a new feature does: more time spent on the problem, earlier prototypes, and questions the requirements gathering questions can help with. Karl Wiegers’ warning sign: a “storm of change requests” right after the requirements are agreed “could be a clue that your requirements elicitation activities were incomplete” (The Line in the Sand).

When requirements change during a sprint

“Can we add more user stories to the Sprint Backlog if the requirements change during a sprint?” has been viewed over 25,000 times on Project Management Stack Exchange. Its author’s situation: “the client insists that we should deliver the changes in the current sprint!” The accepted answer allows it but warns: “It’s not a good practice though as it reduces the usefulness and predictive ability of the methodology” (Project Management Stack Exchange, 2014).

The Scrum Guide draws the line at the sprint’s purpose: “No changes are made that would endanger the Sprint Goal”, while “Scope may be clarified and renegotiated with the Product Owner as more is learned” (Scrum Guide, 2020). In practice:

1. A clarification — the same goal, a detail settled — goes into the sprint.
2. A new requirement goes to the backlog, and the product owner decides when.
3. An urgent new requirement goes in only as a swap. “If new work comes up, it’s not like the Team suddenly becomes able to accomplish more work. So if you are adding work in, take work out” (Project Management Stack Exchange, 2017).
4. A change that makes the goal pointless ends the sprint: “A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.”

The swap rule has a useful side effect. One team made anyone wanting something new “right now” pick something of equal size to remove: “They hated having to make that choice, so most things just ended up at the top of the backlog for the next sprint” (Hacker News, 2024).

Whatever goes in, the requirement changes first. A story built against the old wording and then patched in code leaves the written requirement and its tests saying the old thing.

When requirements change after sign-off

Sign-off fixes a version, not the future. One accepted answer’s advice for keeping the spec from changing in mid-development: “Make a clear distinction what can be changed and what can not. Communicate it clearly to the stakeholders, make them explicitly sign off on unchangeable things as soon as possible” (Stack Exchange).

After that, every change to the signed version is a change request: written down, sized, decided by someone with the authority, and producing a new version — with the signed one kept as it was. “Treat a requirement change as replacing an old requirement with a new one,” as another answer puts it (Stack Exchange, 2010). Who decides is set out in a change control board, even if the board is one person.

In the customer portal used across these templates, the requirements were agreed as version 1.0 on 28 January. When the head of sales asked for Google sign-in on 3 March (CR-7), it was not added to the work in progress. It went to the board with two options, and option B — new customers only, at half the cost — was approved on 7 March as version 1.3.

When requirements change every week

When changes never stop, three rules help, each with a commenter who uses it:

• A cooling-off period. “You could try setting a minimum age of a new addition / change (not applicable to bug fixes). For example no new changes can be worked on until it is 3 weeks old” (Stack Exchange, 2010). A request that still matters after the wait is worth building.
• A cutoff before each release. One commenter, who learned it “in mission planning while in the Air Force”: “Good Idea Cutoff Line. It’s a designated date and time where we stop adding features to the current version. After this point we are not allowed to add. Only subtract” (r/projectmanagement, 2024). Another: “put a feature lock 2 weeks away from launch. Anything that comes up after the lockdown goes into version 1.1” (r/businessanalysis, 2020).
• Batches. Collect changes and decide them together at a fixed time — a weekly board, a sprint review — instead of one by one as they arrive.

Wiegers explains why the cutoff works: “The closer you get to the release date or the end of a development iteration, the more you should resist changing that release because the consequences of making changes become more severe” (Change Happens).

When a client keeps changing requirements

For an agency or a freelancer, every change accepted without a decision is work nobody pays for. One commenter in a thread on freelance scope creep: “Lost about 15K to a client who wanted “just one more feature” every two weeks, and I kept saying yes because the initial contract was solid” (r/webdev, 2026).

What works is not saying no, but making the cost visible every time:

• Answer with what it moves. “every small request gets a “yes, and here’s what it moves.”” Then: “Three or four asks in, the stakeholder usually starts triaging their own list because the math is sitting in front of them” (r/projectmanagement, 2026).
• Show what they lose. In agile client work, “you can make it very obvious to the customer which features they are losing (or at least deprioritising) each time they add something new, which largely puts a stop to frivolous changes” (Stack Exchange, 2012).
• Agree an allowance for small tweaks at the start, and treat anything beyond it as a change request.
• Write down the changes you agree to for free. Goodwill changes are a fair choice, but an unrecorded one is a change nobody can trace later.

The email that offers a client the choice — add it with its cost, swap it, or keep it for later — is in scope creep in software projects, which covers the changes that slip in without any decision.

What to say when requirements change

The last line is one commenter’s, from a thread on estimating: “Every time the requirements change after that it’s your job to communicate the cost of that change” (r/ExperiencedDevs, 2021).

Keeping the requirements true while they change

A change handled well can still leave the documents behind. After each one:

• Change the requirement itself, with a new version — do not add a new story that contradicts an old one and leave both. See requirements in Jira for how that goes wrong.
• Change the acceptance criteria and the tests with it. “Software quality cannot be measured against requirements which the developers didn’t know at the time” (Stack Exchange, 2023).
• Tell everyone the change reaches — the testers, the people writing the documentation, the owners of connected systems.
• Keep the old version readable, so “what did we agree in March?” still has an answer — see how to track changes to requirements.

When this step is skipped, the requirements and the work drift apart: spec drift.

Checklist for changing requirements

1. Is it a clarification, a change, or a new requirement?
2. What does it touch, and what does it cost?
3. Who decides — and have they seen the cost?
4. When does it happen: now as a swap, next sprint, next release?
5. Is the requirement updated, with a new version, before the work starts?
6. Are the acceptance criteria and tests updated with it?
7. Has everyone it reaches been told?
8. If it was done for free, is it written down anyway?

Where Specroot fits

This is the problem Specroot works on: requirements that change as a series of decided versions, with each change’s cost and reach visible before the yes — and the old versions still there to read. Specroot for agencies and consultancies.