When requirement changes comes during the sprint, who takes the final decision to include or not

Question

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

Answer 1

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.

Answer 2

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

Answer 3

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.