How do you handle change request?

For most changes, yes - you would want to capture it however you capture Product Backlog Items, order it, refine it with the Development Team, and then pull it into a Sprint when there's sufficient capacity. However, if the change relates to a deployed system, you may also need to triage it to determine if it's critical enough to warrant bringing to the team in the middle of a Sprint, but this should probably be very exceptional and not the norm.

@Sally SPO, is this change something that needs to be handled in the current Sprint? 

I am working on a project. My client has asked for a requirement that slightly deviates from the initial terms and conditions agreement. I think its a change request. In agile how do I handle a change request? Do i put the CR in PB and prioritize?

Can you clarify why, in your project, requirements deviation demands special handling?

Any new request has to first identified as change or not. If change control board approves it as CR based on efforts estimation and affected artifacts then only it will be part of PB. 

The Product Owner open assessment includes the following question. The correct answer is the last one. Can you see why?

When can the Product Backlog be updated?

(choose the best answer)

• Never, unless agreed to by the change request 
• Only during Product Backlog refinement sessions if the Product Owner is present
• Only after a Sprint Review if agreed to by the stakeholders
• At any time when done by the Product Owner or at the Product Owner's discretion

Any new request has to first identified as change or not. If change control board approves it as CR based on efforts estimation and affected artifacts then only it will be part of PB. 

Vaibhav, while that may be a process you are familiar with, and perhaps practice where you work, none of it is applicable to Scrum.   

The canonical answer is that change requests are not officially part of the scrum process. A change request falls more into the waterfall methodology camp where requirements are loaded upfront and frozen, which necessitates tracking deviations from those frozen requirements in change requests.

Being an agile methodology, Scrum takes care of this intrinsically/seamlessly. The whole premise of agile is the feedback cycle where there's no explicit distinction between what is a change request and what is not because that feedback / change is sought after as a feature of Agile/Scrum not a bug.

Having said that, we live in the real world where in many cases we don't have the luxury to change the whole process an organization follows. In addition, I can argue that there's a use case for Change Requests and that is billability. Although billing could be based on a sprint, yet, it would be nice to track change requests after say an initial definition of what is MVP and what is not.

Having said the above, the simplest way to identify a change request without disrupting the whole process is to simply tag a PBI as such. This can be handled on the field level. Add a tag or a new field where you flag it as a Change Request. That will give you the traceability and reporting capability that your stakeholders are looking for without disrupting current processes.