Introduce or enhance change management process

Establish project change management process and make sure everyone is aware of it to follow
Apply change management in case of updates in resources, schedule, scope, etc
In case of any not planned changes in resources, i.e. decrease or ramp down during sprint execution - then remove sprint tasks this person should have been working on, or engaged any backup or shadow resource to cover this scope
Introduce or enhance micro-change management process on sprint changes level, i.e. document flow how not planned high priority task requested from client’s side can be added to sprint backlog during its execution. Make sure to share this documentation with all stakeholders via email or common meeting. Ensure to monitor and control this process properly.
Prevent changes if possible (eliminate need for changes, or see if changes are not allowed as per charter)
In case of any changes, then evaluate the impact of the change on the other constraints of the project, create options to reduce the impact, get approval from customer, implement change
Make sure to create and track change log
Change requests should include corrective action, preventive action, defect repairs, as well as updates to formally controlled documents or deliverables to reflect modified or additional ideas or content

Useful materials

The customer wants a small change and provides requirements to you
Your team prepares a quick estimation (e.g. T-shirt sizing)
If the change is complex — start a normal change request process
If it is not complex, and you have enough time (for the fast release cycle — about a week, for the Agile-like one — 3-4 days) till this cycle release — prepare detailed estimations
Per detailed estimate, if a change can be done in 4 hours without risks or maximum in 8 hours with all possible risks — you can proceed, everybody is happy. Please do not forget to show results of this extra job to the customer as an achievement of your team.
If Cannot be done (more than 8 hours, regression risks, etc.) — start a normal change request procedure or just move the change to the next release as a regular requirement (depends on the situation)
You can face the situation when the customer wants not just a small change but, for example, ten changes — you should explain why it is not a “micro change” and why the team should process these changes based on a normal change request process.
Ideally, you should remind from time to time: “Dear customer, look here, we have a cool micro-change management procedure, let’s follow it.”

Internal