The full answer
Change is normal. Once users or stakeholders see working software in sprint demos, new ideas appear. The aim of the process is not to resist change but to make its cost clear before anyone commits to it.
When you raise a change, the engineering lead looks at what it affects: design, backend logic, integrations, testing and any features that depend on it. You receive a short summary of the impact and the options available.
Often there is a trade. A new feature can replace something of similar size that is less important, keeping the timeline and budget the same. Alternatively, it can be added as extra scope or moved to a later release.
Every approved change is recorded, so the scope, budget and timeline always reflect what was actually agreed. That record protects both sides and avoids end-of-project surprises.
Changes are easiest to absorb early, which is one reason we show working software every two weeks. Feedback raised in a sprint demo can often be folded into the next sprint with little impact, whereas the same change made after launch preparation has started usually costs more.