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.

2 Answers 2


Change Control Isn't an Agile Scoping Tool

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.

Analysis and Recommendations

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.

Reconsider the Framework Choice

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!

  • Thank you for that - the Project is the first Enterprise Agile project in the organisation and as such the Stakeholders are tentatively embracing Agile - they just want to ensure that the original 1000+ user stories act as some sort of baseline and that the Product Owner does not stray too far from the baseline resulting in 2 or more extra sprints. Commented Aug 6, 2014 at 7:55
  • I am going to suggest pushing for a middle ground - the PO can replace any user stories he sees fit but if he wishes to add more in addition to the original baseline he seeks Change Control when the result creates a Velocity variance of 5% or more. Essentially - if he adds an Epic he gets it signed off to say it will likely impact the timeline. Commented Aug 6, 2014 at 7:56
  • Upvote for spelling it out: this is the antithesis of agility!!!
    – Bernardo
    Commented Aug 6, 2014 at 20:27

I have never done this and it would be a major anti-pattern because:

  1. You are discouraging change
  2. You are excluding the PO from the team, at least indirectly

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.