Use change requests without losing the original scope

Customers need to change their minds when they learn more about a product. Delivery teams also need a stable record of what they originally agreed to provide. A change request should serve both needs. Its purpose is not to discourage learning. It is to make the difference, the consequences, and the authority to accept those consequences explicit.

Keep a baseline that can survive edits

Retain an agreed version of the original scope, its assumptions, exclusions, and acceptance conditions. Link each proposed change to that version. Do not overwrite the baseline with the latest wording and then ask people to remember which obligations changed.

Distinguish a new requirement from a defect or clarification. A defect means agreed behavior is absent. A clarification resolves ambiguity without necessarily adding work. When the classification is disputed, record the competing interpretations and ask the authorized scope owner to resolve them before using the label to allocate effort.

Compare choices rather than quoting one estimate

The Scrum Guide permits scope clarification and renegotiation with the Product Owner as learning emerges, while protecting the Sprint Goal.[1] This does not settle a commercial agreement. Our recommendation is to preserve the contractual approval path while allowing the delivery plan to reflect new knowledge.

Offer meaningful alternatives: add the work, exchange it for another item, reduce the requested behavior, or defer it. Include analysis and testing effort, not just implementation.

• Link the exact original requirement and proposed replacement.
• Identify interfaces, acceptance tests, and support material affected.
• Explain what each option adds, removes, or delays.
• Name the approval authority and unresolved assumptions.
• Update the delivery plan only after recording the decision.

Hypothetical example: a new refund rule

In a hypothetical booking service, the original scope permits full refunds before a cutoff. A stakeholder requests partial refunds after that cutoff. The team records new calculation rules, approval permissions, customer messages, and reconciliation checks rather than treating the request as a small button change.

The sponsor can exchange an unused reporting feature for the refund work, accept a revised forecast, or defer the request. The original full-refund obligation remains visible in each option. If the sponsor selects an exchange, the record names exactly which reporting behavior leaves the current scope.

Close the loop after approval

An approved request is not complete merely because someone signed a document. Connect the decision to revised acceptance criteria, dependent tasks, test coverage, and the customer communication plan. Keep rejected and deferred requests searchable so they do not return later as presumed commitments.

A formal request for every minor wording correction creates delay and administrative cost. Set an agreed threshold for lightweight clarification, but escalate changes that affect obligations, risk, or delivery forecasts. Review one recent change with the customer and team. They should be able to explain the original promise, the accepted difference, and what now remains outside the plan.