Does "Responding to Change" mean we should allow stakeholders to change requirements during the middle of a Sprint?

All answers to this question.

Responding to change applies to the Product Backlog, not necessarily the active Sprint. The "Plan" in the Manifesto refers to those old 12-month rigid project plans that didn't allow for market shifts. To protect your team, you need to educate stakeholders on the "Cost of Context Switching." If a change is truly urgent, it should be discussed in the next Sprint Planning. If it cannot wait two weeks, then the current Sprint should be cancelled and restarted—a move that usually makes stakeholders realize that their "urgent" change might not be so urgent after all.

   Answered 2024-05-12 by Kimberly Thompson

Are your stakeholders part of the Sprint Review? Often, if they see the progress being made, they are more willing to wait for the next iteration to introduce their new ideas.

   Answered 2024-05-15 by David Harris

• David, they do attend, but they often use the Review as a place to demand changes for things we just finished. It feels like we are in a constant loop of rework. We are trying to implement a firmer "Lock-in" period for the Sprint, but the business side claims it's not "Agile" enough.

     Commented 2024-05-17 by Paul Nelson

Agile is not an excuse for chaos. A plan is still necessary; it just needs to be flexible enough to survive reality. You need a "Definition of Ready" to stop half-baked changes.

   Answered 2024-05-20 by Jessica Carter

• Exactly, Jessica. Following a plan is still 49% of the equation. Without a baseline, you aren't responding to change—you're just reacting to noise.

     Commented 2024-05-22 by Sarah Jenkins