I have heard many industry professionals, including senior managers and software developers, criticizing Scrum because, once a Sprint starts, you cannot change the scope (i.e., the work to be done).
And they justify that this is the reason for, in their opinion, Scrum not being effective in handling uncertainty; they prefer Kanban.
In this article, I won’t discuss Scrum vs. Kanban because before going there, we need to answer the question: “is the scope of Scrum’s Sprints fixed?”
In this article, we will explore the answer to this question!
A QUICK STORY
Suppose you and a group of friends are on an unknown island, and your goal is to go to a lighthouse you can see from a distance.
It is night. It is dark. And you need to reach it before the sun rises.
You set an initial plan for reaching the lighthouse by analyzing the landscape.
You don’t know exactly each step or task you will need to take, but you have something to get started with.
Then, you go.
You start working your way through the unknown path, pursuing the lighthouse.
You will learn along the way.
Unexpected things might happen.
You might even discover that the lighthouse is not a good destination. If this is the case, you will need to stop, reassess, define a new destination, plan your way, and keep moving.
What does this have to do with Scrum? Everything!
Before discussing this analogy further, let’s briefly recap the work done during a Sprint.
SCRUM CONCEPTS
During Sprint Planning, the Scrum Team creates the Sprint Backlog.
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). (Scrum Guide, 2020)
Sprint Goal
The Sprint Goal is an achievable objective that can be accomplished during the Sprint and guides the Scrum Team in prioritizing and coordinating the Sprint’s activities.
I will not get into details of how to create a good Sprint Goal here, but, as a rule of thumb, it should give the Scrum Team flexibility. In other words, typically, if the Sprint Goal requires getting Done with all the selected Product Backlot items, it is not a good Sprint Goal.
The Scrum Team should have room to remove or break down some of the selected Product Backlog Items while still fulfilling the Sprint Goal.
RELATING SCRUM TO OUR STORY
In our story, our initial destination was the lighthouse, which would be the Sprint Goal in Scrum.
Our initial plan describing what we think we need to do to reach the lighthouse would be the remaining of the Sprint Backlog (i.e., the selected Product Backlog items along with an actionable plan).
Since we are assuming to enter an unknown path, we will learn, and the plan might change along the way. In Scrum, this is represented by having an emergent Sprint Backlog:
… the Sprint Backlog is updated throughout the Sprint as more is learned. (Scrum Guide, 2020).
Further, if we discover that the lighthouse is not a good destination, we stop and plan a new one. In Scrum, this is represented by canceling the Sprint and planning a new one with a new Sprint Goal.
MANAGING SCOPE CHANGES DURING A SPRINT
Now, let’s get more technical and discuss in detail the possible scenarios in which a change can impact the planned work for a Sprint.
Can the Sprint Goal change during the Sprint?
No!
The Sprint Goal is the reason for the Sprint to exist. If it changes, it is obsolete, and the Product Owner should cancel the Sprint. Typically, this should be a rare event, and a cause for it to happen frequently could be the Scrum Team creating poor Sprint Goals.
For this reason, the Scrum Guide says:
During the Sprint: No changes are made that would endanger the Sprint Goal; (Scrum Guide, 2020).
Typically, since the Sprints are short, waiting for the next Sprint to work on the changes is fine.
Rule of thumb: the more uncertain the environment, the shorter the Sprints should be.
Following this rule of thumb will make handling changes easier.
What if the changes are critical and must be done immediately?
There are two cases in which you can’t wait until the next Sprint to work on the changes.
Case 1: We have already discussed the first and, ideally, less frequent case: it endangers the Sprint Goal. If it endangers the Sprint Goal, it means it is obsolete, and the Product Owner should cancel the Sprint.
Case 2: The second case is when it doesn’t endanger the Sprint Goal because the Scrum Team has room to accommodate the changes. Having such flexibility is expected and desired, as described in the Scrum Guide:
During the Sprint: … Scope may be clarified and renegotiated with the Product Owner as more is learned. (Scrum Guide, 2020)
In this case, in general, the Scrum Team has two options:
- Remove a few of the selected Product Backlog items. Naturally, you would remove the ones not essential for fulfilling the Sprint Goal.
- Break down one (or a few) selected Product Backlog items into smaller ones. The goal here is, for each selected Product Backlog item, only keep the work essential for the Sprint Goal. Then, you create new Product Backlog items for the remaining work and add them to the Product Backlog for future consideration.
EXAMPLE
Let’s see a real-world example to understand how this works in practice.
Suppose you have a Scrum Team working on a Web application that is already live in the production environment. In other words, real users are already using it.
The Sprint has already begun.
And on the 4th day of the Sprint, a critical bug is found on the Web app that is annoying many users.
The Customer Support manager calls the Product Owner and highlights that the bug must be fixed immediately.
In this case, clearly, the Scrum Team cannot wait until the next Sprint.
Thus, the Developers start working on fixing the bug immediately.
Usually, the Scrum Team is able to fix the bug and keep pursuing the current Sprint Goal by removing a few of the selected Product Backlog items to open space for the new work (i.e., fixing the bug).
In a very catastrophic scenario, the Scrum Team would have to cancel the Sprint and create a new one, focusing only on fixing the bug.
TLDR: Key Takeaways
Saying that Scrum’s Sprints have fixed scope is a myth.
The Sprint Goal is fixed, but the selected Product Backlog items can change during the Sprint through discussions between the Product Owner and Developers.
Learn More
You can learn more about effectively applying Scrum by taking my Complete Agile Scrum Master Certification course at Udemy.
.
