Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
In your experience, have you found it beneficial to enforce Change Control upon a Product Owner after the Product Backlog has been agreed?
IE If he/she wishes to change the scope by adding in/taking out/re-prioritizing the Backlog the PO must submit a Formal Change Request/IOCA before taking an approved Change to the Scrum Master for Planning consideration.
If he/she wishes to change the scope by adding in/taking out/re-prioritizing the Backlog the PO must submit a Formal Change Request/IOCA before taking an approved Change to the Scrum Master for Planning consideration.
This is the antithesis of agility. While Scrum works just fine in environments that require formal change control, the change control process is generally intended to safeguard the integrity of the production environment rather than keeping the Product Backlog sacrosanct.
I suspect the "change control" requirement is really an attempt by the stakeholders or steering committee to control project scope or budget. If that's the case, the Scrum Master needs to educate the organization better on how iterative development actually works, and work with the team to ensure that the product is always in a releasable state at the end of each iteration.
The stakeholders, through the Product Owner, can add or remove items from the Product Backlog at any time. The only thing they can't do is change the stories within the current Sprint unless the Product Owner calls for an early termination and a return to Sprint Planning.
Technically, there's nothing in Scrum that requires or prevents stakeholders from enforcing change control on the requirements they pass on to the Product Owner. How the Product Owner interfaces with stakeholders is an externality to the Scrum framework, which simply mandates that the Product Owner is in charge of the contents and ordering of the Product Backlog.
However, such heavyweight quarterbacking is a significant "project smell" that typically indicates that the organization has not embraced the iterative development model, and probably doesn't understand how to effectively use the framework's built-in process controls. Educating the organization about the Scrum framework is the Scrum Master's job, and effectively managing the stakeholders is the Product Owner's job.
Education would seem to be the missing ingredient here. Of course, Scrum is also not a silver bullet, is not right for every organization, and may simply be a bad fit for a command-and-control organization. Good waterfall isn't any more likely to fail than improperly-implemented Scrum, so it may also be worth reconsidering whether Scrum is the right framework for the organization.
Different frameworks may fit better. Your mileage can certainly vary!
I have never done this and it would be a major anti-pattern because:
Having said that, this has happened many times. At the end, it has to be about the sprint goal's relevance to the business. If the PO has something relevant to the goal, then I encourage the team quickly decide what changes should be made without inflating the velocity. If it is irrelevant, then I let the PO decide whether we should stop the sprint and start a new sprint. 100% of the time the PO understanding the stopping and starting of a new sprint will be far more expensive than adding making some "urgent changes".
Finally, it is not uncommon for teams to work in a traditional manner (BDUF, Waterfall, etc) while employing particular agile practices like the role, daily scrums and sprints. This is not Scrum but is still better than no intervals to "inspect and adapt". I suspect this may apply to you, so establishing barriers to change to keep the project moving forward and within scope may be necessary.
