Myth: The Sprint Backlog can’t change during the Sprint
Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘myth-busters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. The great visuals are by Thea Schukken.
If you prefer, you can also listen to us reading this post.
Do Development Teams commit — essentially promise — to complete all the items on the Product Backlog each sprint? Can new insights during the Sprint result in changes to the Sprint Backlog? Or is it fixed? In this post, we address the myth that the Sprint Backlog is fixed during the Sprint.
What does the Scrum Guide say?
The Sprint Backlog represents the work that a Development Team needs to pull from the Product Backlog to achieve the Sprint Goal. The Sprint Goal is an objective set by the Scrum Team during Sprint Planning and captures the hypothesis that the team wants to test, a goal it wants to achieve or an experiment to run. Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not. This returns us to a core premise of Scrum: complex work is highly unpredictable and can’t be planned in detail. Even if that future is a single Sprint, the understanding of the work that needs to be done will be refined and changed as the days progress.
For example, a Development Team might learn that a technology they picked does not perform as expected. Or a key feature needed to reach the Sprint Goal was missed during the Sprint Planning. As issues emerge, changes to the Sprint Backlog may be necessary in order to reach the Sprint Goal. The Development Team collaborates with the Product Owner to change the Sprint Backlog accordingly. In summary: a Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.
Of all the events in Scrum, the Daily Scrum in particular presents Development Teams with an excellent opportunity to inspect and adapt upon their progress to the Sprint Goal and make adjustments to the Sprint Backlog when deemed necessary.
About commitments and forecasts
An important source of confusion stems from earlier versions of the Scrum Guide. They used to explain the Sprint Backlog as something that Development Teams “commit” to. Although not intended that way, some readers took this as something they could hold Development Teams accountable for. Because the intention of the Scrum Framework has always been to work empirically in the face of complex work, and to inspect and adapt throughout the Sprint, the guide now describes the Sprint Backlog as a “forecast” by the Development Team of the work needed to achieve the Sprint Goal by delivering a “Done” increment. It is perfectly fine — even natural — for Sprint Backlogs to change during the Sprint as Development Teams learn more about what is needed, and adapt accordingly.
Although Development Teams don’t commit to the Sprint Backlog, there are plenty of things they do commit to:
- They commit to do the best they can to achieve the Sprint Goal. ;
- They commit to delivering working, high-quality software;
- They commit to continuously inspect and adapt;
- They commit to collaborate with whomever they need to collaborate with during Sprints to achieve the Sprint Goal;
- They commit to the values of the Scrum Framework;
Another way to look at the Sprint Goal and the Sprint Backlog is this; where the Sprint Backlog is the expected output, the Sprint Goal is the desired outcome that Scrum Teams want to achieve. Instead of trying to cram as much as they can into a Sprint, instead the goal of Scrum Teams is to reach the desired outcome (the Sprint Goal) with the least amount of output (Sprint Backlog).
Tips
So what you can do to help Scrum Teams work effectively with their Sprint Backlog? It helps to embrace the emerging nature of the Sprint Backlog. Instead of trying to keep the Sprint Backlog stable, encourage Development Teams to change, refine and improve items as they go. If new work is discovered, the Development Team adds it to the Sprint Backlog. If work proves to be unnecessary, it is removed. It’s up to the Development Team to make these changes and collaborate with the Product Owner where necessary. Changes done to the Sprint Backlog are are always done with the purpose of achieving the Sprint Goal by delivering a “Done” Increment.
Closing
In this blog post, we addressed the myth that the Sprint Backlog does not change during the Sprint. We used the Scrum Guide as a reference and explained the difference between “commitments” and “forecasts”. What’s your take on this myth? We are always eager to learn from your experience.
