Permit changes to the Sprint in Scrum?

Sparked by a recent article on LinkedIn, I would like to say a few words about changes to the Sprint. Some people consider the Sprint plan sacrosanct, others want to define a rule set for changes - yet others are very open-minded about changes within the Sprint. What is a good idea, what isn't?

Is the Sprint Plan fixed?

Many teams assume that a Sprint is immutable, and the Scrum Guide advises fixing the Sprint content as well.
This provides safety and a certain level of comfort for the team. Developers know well ahead what to do. The team can reliably forecast how well they will achieve their plan with a high degree of confidence. That's the plus side.

There are a number problems with this, such as:

1. Plans must be made upfront with a high degree of detail - possibly at a time when the best solution is not yet known.
2. Unnecessary features ( = waste) may be delivered if they made it into the Sprint backlog - resulting in additional rework in the future
3. Opportunities that become known during development are not monetized immediately - reducing the possible value delivery of the team

All these points are violations of the Agile Manifesto, so you should be careful with statements that "Scrum supports this". Yes, it does - but only to a certain extent, less your Scrum becomes un-agile.

There are good reasons to keep the Sprint scope fixed regardless, for instance to protect the team against whimsical stakeholders who consider "everything urgent" and who come up with "even more urgent" things on a daily basis.
Keep in mind, however, that this is a different problem from the problem which work developers do and when they fix their plan.

When is changing Sprint content a good idea?

Instead of proposing a huge rule set, there is a simple guideline: "When it makes more sense to change the plan than to pursue it" (ref. Agile Manifesto value #4: "Responding to change over following a plan")

Here are some of the main reasons when it makes sense to change - you may find others:

1. The team decides it is so.
2. The product is dysfunctional until the change is implemented.
3. A stakeholder has a very urgent need and is willing to pay the price.
4. Not making the change would damage the credibility and reputation of the team

How do we change the Sprint?

The Scrum Guide suggests "Sprint termination". A Sprint termination means: "We stop everything we're doing, end with a Retro and restart with a new planning". That may indeed be an option if the change proposal makes the entire remaining Sprint unfeasible. It may not be necessary if the upcoming change is of a lesser nature.

Here is what needs to be done, at a minimum:

1. Estimate the change: How much of the Sprint's remaining capacity will be redirected?
2. Re-Plan Sprint Backlog: Pull enough items out of the Sprint to fit in the change, then add the changed item.
3. Plan the change: The change needs to be subjected to the same kind of item planning as any other item that is already within the Sprint. This may require an extraordinary planning meeting.
4. Inform stakeholders: Some items won't be touched by the team because of the change. They may either return to the Product Backlog or be discarded entirely.

What happens after we changed the Sprint Backlog?

We shouldn't be doing that on a daily basis. It should remain a special event. At the end of the Sprint, the team reflects in a Retrospective why this change occurred.

Here are a few questions the team might want to ask:

1. Why do we see changes to the Sprint Backlog as a problem?
2. Why are we getting these kinds of late-and-urgent changes?
3. Did we do our best to clarify the impact of the change?
4. Did we do our best to minimize the effort and scope of the change?
5. How could we have discovered this information earlier?
6. How can we increase their agility to deal with this type of change easier in the future?

The Retrospective should result in conclusive actions for improvement.

Summary

Changes to the Sprint shouldn't be the end of the world. In a domain with high uncertainty and rapidly changing outward circumstances, change should be a normal thing. When it makes sense to change, you can not hide behind Scrum rules to justify actions that don't make sense.

Apply common sense.