If change request is pushed by the client during the sprint aggressively, who takes the final decision if it needs to be included or not
When requirement changes comes during the sprint, who takes the final decision to include or not
1What do you mean by "in between the sprint"? Are you referring to during a Sprint, such as some time after Sprint Planning?– Thomas Owens ♦Jul 24, 2019 at 14:10
1"In between Sprints" implies "after Sprint A ends and before Sprint B starts". "During a Sprint" implies "after Sprint A starts and before Sprint A ends". "In between the Sprint" is meaningless and not understandable. Please pick one of the above.– SarovJul 24, 2019 at 14:17
In Scrum, there is no concept of "in between the Sprint" - the end of one Sprint immediately leads to the start of the next. I suppose it could also lead to the termination of the effort in the case that there are no more Sprints.– Thomas Owens ♦Jul 24, 2019 at 14:48
1Being a non-native speaker myself, I'd guess the intention was "comes in"... "during sprint". In this case, the between is not the recommended word. Once OP confirms, we can rephrase it and remove all comments.– Tiago Cardoso ♦Jul 24, 2019 at 19:14
That's my bad.. its during sprint.. Thanks Tiago.. Edited– sumitJul 25, 2019 at 4:55
The final decision is up to the product owner. If it's really, really, really important, the product owner could just cancel the current sprint and start a new one with just this single story in it.
Please note that that is an extreme measure and normally the product owner should consult the team about it and figure out a good way for all participants. But prioritization is the product owners domain. They say what is important and what needs to be done first.
@sumit I want to add that customer expectation is an KEY part of the quality assurance in your projects. Understanding this, you will reduce rework. As your are in a Scrum framework, then scope should be done at the beginning of each sprint. It should be validated and controlled. As others have said, PO must reduce changes during the current sprint, because it will create scope creep. Before to act, you may explain clients how you manage iterations and wait for the next wave. If it is something critical, then the scope of work for that sprint failed. Do lesson learned and correct next sprint. Jul 26, 2019 at 1:36
First and foreMost, it is the responsibility of the product owner to decide the requirement change should be included in the current sprint or not. Obviously , this involves more development work and chances of pill overs in the sprint. Ideally the product owner prioritize the requirement change over other stories and deliver based on that . And finally, it is all about agile framework. Changes are always welcome in the agile development to improve the quality of the product
I consider nvoight's answer to be mostly correct, but there are other considerations.
In Scrum, the Product Owner is accountable for managing the Product Backlog. In the context of handling requested changes, the Product Owner is the one who needs to remain accountable for ensuring that the request is reviewed, expressed appropriately, and ordered with the rest of the Product Backlog Items. The Product Owner also collaborates with the Development Team on an ongoing basis to refine the Product Backlog Items.
However, I'd also argue that the Scrum Master has a role to play. One of the responsibilities of the Scrum Master is to help stakeholders understand empirical product development, Agile Software Development, and Scrum. The stakeholders are only only the Product Owner, the Development Team, and the development organization, but also include clients.
I would be quite concerned if a client, in the middle of a Sprint, was aggressively requesting changes. I would have a few approaches and, if I were in a coaching role with the team, would work very closely with the Product Owner.
The first thing I would look at is the Sprint cadence. Sprints are typically between 1 and 4 weeks long, with 2 and 3 week Sprints being the most common. Outside of a critical defect that is preventing work from happening, I would question why the change could not wait until the next iteration. I would consider that if this was important enough, a potentially shippable increment can be produced before the end of the next Sprint that included just the priority change - Scrum allows for, and techniques such as continuous integration and continuous delivery enable, multiple potentially shippable increments to be provided during a Sprint.
For non-critical issues, I would encourage placing the changes at the top of the Product Backlog and ensuing appropriate time with the team to understand and refine the work. Doing this will likely yield higher quality work. By giving the team time to understand the need or want, work with the Product Owner to refine it and estimate it, there is a better chance of the work being done right. In addition, if the change is extremely high risk or requires a large amount of effort, the Product Owner will be able to manage stakeholder expectations or work out a plan to decompose the work and slowly introduce the changes in an appropriate timeline.
Cancelling a Sprint is an option, if the change request is deemed important enough and cannot be done with the current capacity. However, the Scrum Guide uses the phrase "traumatic" to describe cancelling a Sprint due to its disruptive nature. Also, cancelling a Sprint may not be possible in a scaled environment where multiple teams are synchronizing their Sprints and have dependencies.