Working agile is all about embracing change, as the request for change is typically a sign that we’ve learned something and need to adapt accordingly (i.e., empiricism in action). However, if changes happen too often, it’s difficult to do anything meaningful, so we have planning events to identify the work we’ll probably do to deliver the expected outcomes. In Scrum, at Sprint Planning, we discuss why the upcoming Sprint is valuable, what work can be done in it and how. In SAFe, at PI Planning, we align the teams in the ART on the objectives of the next Program Increment.

It can happen that our plan has to be changed immediately after we’ve made it, but since we’re not plan-driven, we must embrace it. Just make sure to challenge the validity of the request for change, and whether it really has to be made now–you, as the Product Owner, can help shield the Scrum Team from unnecessary changes by empathically saying ‘no, not now’, e.g., if a Manager forgot to inform you on a request in time.