Skip to main content

How do you handle change request?

Last post 12:36 pm April 17, 2022 by Ronald Norman
7 replies
09:52 pm November 17, 2019

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?


11:28 pm November 17, 2019

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.


01:01 am November 18, 2019

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


09:45 am November 18, 2019

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?


12:08 pm November 18, 2019

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. 


02:22 pm November 18, 2019

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

04:54 pm November 18, 2019

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.   

 

 


09:37 pm April 15, 2022

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.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.