You’ve agreed a release, development is under way, and someone spots a requirement that wasn’t in the plan. Perhaps users need an approval step. Perhaps a supplier’s system behaves differently from expected. Perhaps seeing the first working version has prompted a better idea.
That’s not automatically a problem. Agile software development makes room for learning as you go. The difficulty starts when a new requirement quietly becomes a commitment, while the budget and release date stay untouched.
We recommend a simple habit: record the change, assess its impact, agree the trade-off and update the plan. Here’s how to make that work without turning every conversation into paperwork.
1. Keep a clear starting point
You can’t assess a change if nobody knows what you’re changing from.
Before delivery begins, agree the release outcome, the work currently included and the constraints that matter. Keep these somewhere both the delivery team and business stakeholders can access.
Your starting point should cover:
- The outcome: what users should be able to achieve after release.
- Included work: features and acceptance criteria, meaning the conditions that show the work is complete.
- Boundaries: what is explicitly excluded or intended for later.
- Constraints: budget, target dates, dependencies and essential quality requirements.
- Decision owners: who can approve priorities, spending and release changes.
This isn’t a promise that nothing will change. It’s a shared reference for discussing what changes mean.
2. Record the request before committing to it
A request in a meeting or chat is easy to misremember. Give it a short, durable record in your existing backlog or project tracker. You don’t need a separate system.
Capture the problem before jumping to the proposed feature. “Staff need to correct an order before dispatch” leaves room to explore options. “Add an edit button everywhere” assumes the answer before anyone has checked the consequences.
Use this reusable change record:
- Change ID and title: a reference people can find again.
- Requested by and date: who raised it and when.
- Problem and affected users: what isn’t working, or what opportunity has emerged.
- Proposed behaviour: what should happen differently.
- Acceptance criteria: how you’ll judge whether it works.
- Urgency: why it is needed now, including any genuine deadline.
- Status and owner: who will assess it and what happens next.
First check whether it is genuinely new scope. A fault against agreed acceptance criteria is different from an enhancement. If the distinction is disputed, review the agreement together rather than labelling everything a change request.
3. Assess the whole impact, not just the coding
Ask the delivery team to assess the change before promising a date or price. Include design, development, testing, release work and any documentation or training it needs.
Check dependencies too. A small interface change might require new permissions, data migration or an external service that isn’t ready.
The assessment should explain:
- Effort: the likely work involved, expressed as a range where uncertainty remains.
- Cost: the effect on the agreed budget or commercial arrangement, including relevant third-party charges.
- Timing: whether it affects the current delivery cycle, release date or other milestones.
- Disruption: work already started that may need revisiting or stopping.
- Risk: security, privacy, reliability and operational consequences.
- Unknowns: what needs investigation before the estimate becomes useful.
If a supplier dependency is unclear, propose a short investigation with an agreed limit and a specific question to answer. Don’t disguise missing information as a precise estimate.
Keep effort and elapsed time separate. Two days of work won’t necessarily be finished two calendar days from now: availability, reviews and external dependencies matter.
4. Put the trade-offs on the table
“Can we add this?” needs a more useful answer than yes or no. Present workable options:
- Swap it in: remove or defer other work to protect the budget and target date.
- Extend delivery: retain the existing scope and agree the additional budget and time.
- Reduce the change: deliver a smaller version that solves the immediate problem.
- Defer it: keep the request visible for a later release.
- Decline it: record why it doesn’t support the current outcome.
If you propose a swap, name exactly what moves out. “We’ll trim a few things” leaves everyone with a different picture.
Don’t assume equally sized estimates make a swap neutral. Work already completed, shared dependencies and testing needs can alter the balance. Protect essential security, accessibility and reliability requirements rather than treating them as convenient savings.
5. Make the decision explicit
The person requesting a change may not have authority to approve its cost or release impact. Route the decision to the agreed owner, with input from those affected.
Imagine a hypothetical booking system project. During a review, the operations team asks for supervisor approval before certain bookings are confirmed. A dashboard is already planned for the same release.
The team could propose moving the dashboard to a later release and adding a limited approval flow instead. Before approval, they would check whether that swap actually fits the available capacity and whether deferring the dashboard leaves staff with a workable reporting process.
The decision should state which bookings need approval, who can approve them, what happens while approval is pending and which dashboard work is deferred. It should also record any revised cost, timing assumptions or unresolved dependency.
That is much clearer than “approval feature agreed”.
6. Keep a decision log alongside the backlog
The backlog shows what needs doing. A decision log explains why the plan changed.
For each decision, record:
- Date, change ID and approver.
- Decision: approved, deferred, declined or awaiting investigation.
- Reason: the outcome or constraint that drove it.
- Scope added and scope removed: linked to the relevant work items.
- Budget and timing impact: including assumptions and uncertainty.
- Next action and owner: who updates the plan or resolves an outstanding question.
Use a short entry with links, not a transcript of the discussion. Preserve earlier decisions when plans change again so the history remains understandable.
Approval isn’t the last step. Update the backlog, release forecast and any commercial documentation required by your agreement. Tell affected stakeholders what changed, particularly when something they expected has moved out.
7. Review changes at a sensible rhythm
Review ordinary requests during regular planning or prioritisation. Avoid interrupting active work simply because a request is new.
Urgent issues need a faster route. Assess their impact on the current delivery goal, agree what pauses and record the decision promptly. If you use sprints, discuss changes with the people responsible for that sprint’s work rather than silently inserting extra tasks.
At each review, check that approved changes have reached the plan, deferred requests remain visible and forecasts still reflect reality.
The aim isn’t to stop scope changing. It’s to make each change a conscious choice, with a clear benefit and an understood consequence.
If your backlog and release plan are telling different stories, let’s talk. We can help you work through the priorities and agree a practical next step.