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 ‘mythbusters’ Barry Overeem & Christiaan Verwijs - will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken.
Myth: The Sprint Backlog can't change during the Sprint
The myth is that the Sprint Backlog is fixed during the Sprint. The Development Team commits itself to implement all the items on the Sprint Backlog. Changes are not allowed during the Sprint; no work can be added or removed. This offers the team the necessary focus to fulfil their given commitment.
Why is this a myth?
Busting the Myth
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 would be unwise considering the core premise of Scrum: we can't create detailed plans for the future. Even if that future is a single Sprint, it is entirely possible that new insights or impediments emerge as the Development Team works through the Sprint Backlog.
A 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 warranted in order to reach the Sprint Goal. The Development Team will then re-negotiate the Sprint Backlog with the Product Owner. In short; a Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.
The Daily Scrum 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.
While the Sprint Goal is set in stone, the Sprint Backlog is a forecast of the work needed to achieve the goal
About Commitments and Forecasts
Related to this myth, the Scrum Guide has changed a couple of years ago. In the context of the Sprint Backlog, the word “commitment” was replaced by “forecast”. It describes the Sprint Backlog as a forecast by the Development Team about the functionality that will be part of the next Increment and the work needed to deliver that functionality into a “Done” Increment. This underscores that insights and unexpected issues are likely to emerge during development - even within a single Sprint.
However, commitment is still relevant for the Development Team; they commit themselves to:
- Fulfil the Sprint Goal;
- Delivering working, high-quality and usable software that meets the expectations of the customers and users;
- Working only on the Product Backlog items with the highest value;
- Focus on continuous improvement, learning, and technical excellence;
- Continuously inspect and adapt, by which empiricism is supported;
- Collaborate with all the business people involved;
- The values and elements that build up the Scrum framework.
Where the Sprint Backlog is the expected output, the Sprint Goal is the desired outcome that we want to achieve. Instead of trying to cram as much as we can into a Sprint, our goal should be to reach the desired outcome (the Sprint Goal) with the least amount of output (Sprint Backlog).
Embrace the emerging nature of the Sprint Backlog. Encourage the Development Team to change, modify and improve the Sprint Backlog during the Sprint. If new work is required, the Development Team adds it to the Sprint Backlog. If work proves to be unnecessary, the Development Team removes it from the Sprint Backlog. It’s up to the Development Team to apply these changes and inform the Product Owner if this is considered necessary. Any changes done to the Sprint Backlog are done with achieving the Sprint Goal in mind and building a “Done” Increment.
Closing
In this blog post, we’ve described the myth that the Sprint Backlog is fixed during the Sprint. We’ve busted this myth by offering the perspective from the Scrum Guide and describing the difference between forecast and commitment.
What is your opinion about this myth? We are always eager to learn from your experiences as well!
Want to separate Scrum from the myths? Join our Professional Scrum Master or Scrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses.