Accepting Change during Sprint is a negotiation; it’s not cast in stone. Agile is Individuals and interactions over processes and tools.

The development team commits itself to implementing all the items on the Sprint Backlog.?Changes are not allowed during the Sprint; no work can be added or removed.?This is a myth that most people hold. The new scrum guide, however, has done justice to this myth and clarified many of the misunderstandings.

Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not. To start with, please understand that agile is, first, a set of values and principles. The different frameworks are there to assist teams and organizations in their journey towards agile transformation.

One of the agile values is – “Responding to change over following a plan”.

Still, another value states that Individuals and interactions are preferred to processes and tools. Processes and tools are good and required most times but the people behind them and the interactions are much more important.

One of the agile Principles is – “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” As we go ahead in this article, please keep these two values and principle in mind. It will help you to unravel the myth and understand why scrum guides itself has been reviewed to keep up with our VUCA (Volatile, uncertain, complex and ambiguous) world.

A common misunderstanding many people moving from waterfall to scrum make is that the project plan is the same as the sprint plan. They view the Sprint plan as a project plan. The team committed to delivering the scope in the project plan on a specific date, so why wouldn’t they commit to delivering everything in the Sprint Backlog at the end of the Sprint?? Please understand that Scrum was created to solve problems in the complex domain through adaptive solutions and iterative approach. We call it progressive elaboration. This means that we don’t have all the solution now but as we go ahead in development, new knowledge will show up and we will adapt.

Problems in the Complex domain are not predictable. In the Complex domain, the relationship between cause and effect is not known upfront and can only be deduced in retrospect. We have unknown unknowns. Said another way, we don’t know what we don’t know. That means no matter how much analysis we do up front, we cannot accurately predict what will happen. The Cynefin model helps to understand what defines problems in the complex domain.

To go back to the topic. Yes, the sprint backlog can change during the sprint as long as it does not endanger the sprint goal. Requirements can be welcome during the sprint but it’s a negotiation. My main message here is that it’s a negotiation (not cast in stone) between the development team and the product owner or stakeholder pushing for it. One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” regarding the work selected for a Sprint.?

“Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.” - Scrum Guide

“If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.”?– Scrum Guide

The wording is important here. A forecast is not a commitment and allows for flexibility. Please note scrum is founded on empiricism which tells us we should base our decisions on what is known, not the unknown complexity ahead of us. By committing to scope (the Sprint Backlog), there is an implied expectation that we know everything about the complex product we are developing and therefore, everything will be delivered “on time” at the end of the Sprint. Software resides in the complex domain. We’ll never know everything up front. We have to figure it out as we go. Yes, different fields like health, legal, HR etc are now adopting scrum but it was originally developed for the software industry.

The reason many scrum teams push against “change within a Sprint” are not far-fetched. Here are some real-world examples:

• Many teams believe change is not acceptable during sprint.
• The development team and/or the manager are new to Agile – they still see each requirement change as a disruption to the current flow. They are still trying to find their velocity.
• It being a fixed cost project, and may be a little behind schedule. The team wants to avoid any attempt to delay the project any further.
• Management is known to use velocity as a key indication of individual and team performance. Hence, any requirement change during the sprint, however small, is looked down upon by the team.
• The Product Owner (PO) is too busy to groom stories in a timely manner and often ends up giving half-baked stories to the team. The team does not want to pay for the PO’s mistakes. This is very common.
• The PO – being from the customer side – is always keen to slide new requirements into existing stories in order to maximize return on investment.
• The PO is eyeing an upcoming opportunity and wants to leave no stone unturned to impress the customer. Sliding small changes into the sprint is too easy an opportunity to miss.

?As mentioned earlier, accepting change within sprint is a negotiation (Individuals and interactions over processes and tools). You can welcome it, or you may push to the next iteration. Below are some important considerations that may help the team to decide if they should welcome change or not:

• The size of the change While taking a small change may enhance agility, a big change may disrupt the flow of the sprint.
• The timing of the change Changes early in the sprint may be preferred rather than towards the end of the sprint. Agile principles says we should welcome change even late in development. So, it still boils down to negotiation with the PO or stakeholder.
• The source of change – Is it: A requirement that was missed by PO or BA? A change requested by customer after seeing the product? A change requested by PO based on his gut feeling or has he confirmed his understanding with the customer? Is it a change from top management of the organization as they see what the team is not seeing? Is it a change that is critical to MVP? MVP will not be complete without it.
• The frequency of change: Are such changes occasional or the customer/PO getting into the habit of giving half-baked requirements and then changing them frequently?
• The type of project – is it a fixed cost project ?

?If you are expecting teams to commit to delivering everything in the Sprint Backlog or not to welcome change, you are more focused on output instead of value and quality. By forecasting, the team can focus on quality, value, adapting, continuous improvement and satisfying the customer by delivering a quality increment at the end of every Sprint. As the team matures, they will become more predictable at forecasting the work they can get done in a Sprint.

If you are using scrum in your organization for complex domain like software, please note that you are working in unknown unknowns. You cannot predict everything. You cannot completely analyze upfront.

The spirit of agile is individuals and interactions over processes and tools. In our context, it means you interact and negotiate with the product owner over the change. If the change is necessary and required to meet customer’s demand, so be it. This is the more reason personal agility (through training) is first and foremost required before you form a scrum team. Individuals must first be agile in their thinking.

When we have agile individuals in teams, team agility will be much easier and the team will gain maturity over time and can predict much better even when they accommodate changes.

Adeniyi Oladipupo

Agile Coach and Evangelist

?