Organizations that adopt Scrum often have difficulty understanding why the Product Backlog Items selected for a sprint must remain stable. Because Scrum allows us to “negotiate the scope of the Sprint Backlog within the Sprint,” teams often feel pressured to allow new stories to be added to a sprint mid-flight. When Scrum Masters push back against this pressure, the person applying it may respond by quoting one of the principles behind the Agile Manifesto:
“Why can’t we do that? I thought agile is supposed to ‘welcome changing requirements, even late in development,’” they may say.
Read More: 3 Ways To Tackle Sprint Work That Ends Early
Of course, they’re right—but only partly so. The same principle continues, “Agile processes harness change for the customer’s competitive advantage.” Not all change is created equal. Not all change is worth the cost. Not all change should be welcomed. At some point, we have to hit a pause button on requirements change in order to produce a finished product increment. Otherwise, chaos results.
Scrum helps balance the need for change with the need for stable development environment in these four ways:
1. Empowers the Product Owner
The Product Owner is a very powerful role in Scrum, and part of its power is due to its ability to determine how and when to adapt to change.
The Product Owner is responsible for deciding the priority and order of the backlog—and what is in it. This responsibility means that as the Development Team creates a product increment, the Product Owner can focus on performing market research, engaging with customers, and seeking additional feedback from stakeholders.
All of this information allows the Product Owner to seek a competitive advantage for the customer. The Product Owner may learn of new market demands, discover new customer needs, or develop a new understanding of business direction and strategy that lead to new, emergent requirements. The Product Owner has the power and authority to prioritize new requirements over existing ones, for example, or change existing requirements to better reflect what has been learned.
The Product Owner is the front line in harnessing change for competitive advantage—so make sure you give Product Owners the authority and autonomy they need to maximize the value of the Development Team’s work.
2. Allows Organizations to Establish a Sprint Cadence that Balances Risk and Change
The Scrum Guide does not specify what length sprints must be, except to say that they must be “one month or less.” Within that boundary, each organization can establish a cadence that provides the Development Team the stability it needs to create a product increment without distraction or interruption, but also mitigates against the volatility of the marketplace. For environments in which change is not as frequent, a four-week Sprint may work; however, if planning with a one-month horizon isn’t feasible or is too risky, the organization can opt for a shorter time frame. A good rule of thumb for sprint duration is to use the maximum length that your organization can keep change out of a sprint.
In your organization, choose the shortest responsible Sprint length—long enough that the Development Team can create a product increment that adds value, but short enough to allow for timely feedback.
3. Provides a Mechanism for Customer Feedback
One of the fundamental realities of product development is that people often don’t really know what they want until they start to use the product. The Sprint Review provides regular opportunities for customers and stakeholders to evaluate what has been built so far and collaborate with the Scrum Team to determine the most valuable thing to do next. That collaboration often leads to new or changed requirements that the Product Owner can incorporate into the Product Backlog.
Scrum doesn’t merely allow for changing requirements, it generates them. This is how Scrum “harnesses change for the customer’s competitive advantage”—by encouraging the customer to collaborate with the Scrum Team on changing direction.
Maximize the value of your Sprint Reviews by making sure that they go beyond mere “demo” to true feedback and collaboration events.
4. Offers an Escape Route
It’s always possible that an earth-shaking change in circumstance could arise and make the current Sprint Goal and everything in it obsolete: A competitor releases a product that makes what you’re working on useless. A new regulation demands immediate attention. A security threat requires an immediate patch and drastic architectural modifications.
For dramatic situations like these, Scrum has an escape valve: canceling a sprint. If the Sprint Goal is no longer valid, a Product Owner may decide to cancel the Sprint and start a new one. Only the Product Owner has this authority, although the Development Team, the Scrum Master, or stakeholders may influence the decision.
When a Sprint is canceled, any completed work is reviewed. Incomplete Product Backlog items must be re-estimated and, if they are still valid for the product, are returned to the Product Backlog. A new Sprint Planning event is then held to kick off a new Sprint. It’s an incredibly costly thing to do.
If a Product Owner finds stakeholders demonstrating behavior disruptive to the Scrum team—such as demanding that the team swap similarly-sized stories or add “just this one thing” to the Sprint—they can push back by asking, “Is this change so valuable that it’s worth the enormous cost of cancelling and re-planning the sprint?” If it isn’t, then it can go into the backlog to be prioritized.
Welcome Changing Requirements at the Right Time
Agile rejects the old waterfall paradigm that changing requirements are always a threat to successfully delivering a new product. But that doesn’t mean that change comes without a cost, or that all change is good. By balancing the reality of change with the need for stability for the Development Team, Scrum makes it possible to “welcome changing requirements, even late in development” when it will be most advantageous to do so.