Situation when you are working with a rapidly changing environment - organization structure and strategies is changing, priorities of different clients need to managed in a single sprint, resources/team is also not consistent. Saving Changes...
As said by Aaron and Edward, it is important to make the client to understand, that a team needs focus during an agreed sprint. That means in general the current spring is change-locked. Changes go through a change process and are primarily subject to the next sprint, except in agreed situations where current sprint is re-prioritized and/or team agrees that it still fits into there velocity. Also agree that sprint duration might be too long as a root cause this customer requests come up. Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
Methinks some of you need to go back to the Scrum Guide. I disagree that Muralikesavan "nailed it" as Lisa asserts.
Despite the fact that we "embrace change" as promoted in the Agile Manifesto, it's simply not true that in Scrum we simply accept all proposed changes, at any time.To do so would endanger the achievement of the Sprint Goal and would violate the whole planning process of deciding what goes into the current sprint in the first place.
While the Product Owner can at any time request changes to the Sprint Backlog, those requests may or may not be accepted by the team. This judgment would be made based on how much the requested change disrupts the current sprint or how much it supports, or deviates from, the current Sprint Goal. The Scrum Guide is clear: "Only the Development Team can change its Sprint Backlog during a Sprint". Saving Changes...
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
