The Scrum Guide has been updated in November 2020. What has changed? What lies behind the changes? And what does that mean for your Scrum Team today?
The Agile Manifesto starts with the words: “We are uncovering better ways of developing software by doing it and helping others do it.” One of the values of the Agile Manifesto is ‘Responding to Change’. This not only applies to responding to change in the requirements of the product that you’re developing, but also applies to the way you are working with Scrum.
On Wednesday November 18, 2020 the 25th birthday of Scrum was celebrated in a livestream. Here, the creators of Scrum, Jeff Sutherland and Ken Schwaber, released a new update of the Scrum Guide. The Scrum guide needed an update because ‘responding to change’ also applies to Scrum.
“Scrum at its core is empirical; so all of your insights and experiences are pulled in to making Scrum better.” – Jeff Sutherland.
One thing that stands out is that the Scrum Guide is now shorter. It went from 19 pages down to a mere 13 pages. Less words, better wording. More about what to do and less about how it should be done. For example, what happened to the well-known three questions of the Daily Scrum? The what is in the Scrum Guide and is executed with help of a Scrum Master. The how is for the Scrum team to decide. After all, the team can determine the right solution for their situation best.
Picture: the updated Scrum Framework. Illustration by Linda van Sinten, Creatieve Elephant.
WHAT HAS CHANGED?
1. Scrum is shorter and better formulated for a broader audience.
“Scrum hasn’t changed, we just found a better way to describe it” – Jeff Sutherland & Ken Schwaber
Explanations have become clearer and with less words. Also, now without software development-specific words as for example: ‘requirement’ or ‘testing’. The only word that still relates to software development is ‘developer’. But a developer does not necessarily have to write code. Someone can also develop a curriculum for a study or a media campaign. For some time now Scrum has not been just for the IT department anymore. With this update the Scrum Guide is adapted to that as well.
2. Scrum is less prescriptive.
In an earlier version of the Scrum Guide the creators of Scrum wanted to guide the teams on how to do it. For example, the three questions asked during the Daily Scrum. This led to the wrong situation in (too) many cases. The purpose of a Daily Scrum is to inspect the progress towards the Sprint Goal and to create an actionable plan for the upcoming day. In reality, asking the three questions turned the Daily Scrum into a status meeting. The developers of a Scrum Team can choose how they think their Daily Scrum is best held. As long as it focuses on the progress toward the Sprint Goal and creates a plan. Of course, this has always been up to the team, but now it is reinforced by Scrum. The Scrum Guide describes more about what needs to be done and less how to do it.
3. There is one Scrum Team that works on one product.
Scrum had a separate Development Team within the Scrum Team. This has led to a gap between the Development Team and the Product Owner in many situations. In the new version only one team is mentioned: the Scrum Team. Consisting of one Product Owner, one Scrum Master and Developers. Together, the Scrum Team is accountable for creating a valuable and useful increment, every Sprint. There is no Development team anymore within the Scrum Team. The goal is to eliminate ‘us and them’ behavior between the Product Owner and the Developers and to work as one team together towards a common objective. “We’re all-in this together.” – Ken Schwaber.
Within the team we don’t speak about roles anymore. What the roles of Scrum Master, Product Owner and Developer were, are now accountabilities. The accountabilities are described more clearly now. For example, it is now explicitly mentioned that the Scrum Master is accountable for the effectiveness of the Scrum Team by enabling the Scrum Team to improve its practices.
4. Introduction of the Product Goal.
With the introduction of the Product Goal a future goal for the product is set. All items on the Product Backlog should add up to the Product Goal. It gives an answer to the question ‘What will our Sprints lead to?’ Just finishing all items Sprint after Sprint on a Backlog is not particularly motivating. The Product Goal provides purpose and focus for the team. As a Scrum Team you will want to know what the goal of the organization is. When the team keeps the goal in mind, the Product Goal helps in giving direction when decisions have to be made during development.
5. More emphasis on the Sprint Goal, Definition of Done and the Product Goal.
The three artifacts of Scrum (Product Backlog, Sprint Backlog and the Product Increment) are now accompanied by three commitments. The Sprint Goal and the Definition of Done are not new to Scrum. But by making them commitments, their position is strengthened. The three commitments bring focus and transparency to the artifacts.
a. The commitment of the Product Backlog is the Product Goal.
b. The commitment of the spring Backlog is the Sprint Goal.
c. The commitment of the Increment is the Definition of Done.
Something has also changed in the description of the increment when talking about the Definition of Done: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” In the previous version of the Scrum Guide the Increment was described as: “potentially releasable Increment of “Done” product at the end of a Sprint.” With this change it is suggested that as soon as a Backlog Item meets the Definition of Done, the increment can immediately be released by the Product Owner. Even before the end of a sprint. According to Jeff Sutherland this also enables ‘Swarming’ a Backlog Item. To swarm with the whole team on finishing the most valuable item as quickly as possible before starting the next one. This prevents ‘Waterfalling the Sprint’ where the team members work on all items at the same time and finishing them all up at the end of the Sprint. Time to hone your DevOps!
6. New topic in Sprint Planning: the Why?
Picture: Sprint Planning. Illustration by Linda van Sinten, Creatieve Elephant.
Besides the questions of “What are we going to build?” and “How are we going to build it?” the Sprint Planning now has a third question: “Why are we going to build it?” The Why-question gives a Sprint more clarity about why we are going to do the work. This is tightly linked with the new Product Goal. Why does this Sprint give value to the product or to our stakeholders?
With this addition the creators of Scrum want to prevent Scrum Teams becoming ‘feature factories’ who just try to finish all the items in the Sprint Backlog. While working on complex problems new insights are gained almost daily and these insights can change the scope of the sprint. By answering why this sprint is important direction is given to making decisions during the work of a sprint. Perhaps the most frequently used Sprint Goal is: “Finish all the items in the Sprint Backlog.” Now you will not get away with this anymore!
7. Different wording: self-managing and no more servant-leader?
The Scrum Team is no longer self-organizing but it is now: self-managing. I say potato, you say potatoe. It might seem like that with this subtle change of wording but there is much more behind it. With the new focus on the Scrum Team as a whole, the creators wanted to emphasize that the team is responsible for determining who works on what and how the work is done.
The Scrum Masters’ definition ‘servant-leader’ also did not stay out of harm’s way. The accountability of Scrum Master is now described as a ‘true leader who serves the Scrum Team and the larger organization.’ The term servant-leader was often misinterpreted. Because of putting the servant-part in front, the Scrum Master was often seen as someone who was mostly a secretary for the Scrum Team. Not as someone who is accountable for the improvement of the team. By reversing the words and bringing the word leader to the front, the focus is back to the most important thing: leadership.
8. No more estimations?
Where is the word ‘estimation’? Three paragraphs about estimating and refinement are brought back to one paragraph with just twice the word: size. How (and if) you estimate items on the Product Backlog on size/time/effort or value is up to you. It is also no longer prescribed how much time you should spend on doing this. Scrum doesn’t care if you are using story points, T-shirt sizes or #noestimates, it is up to the team. In the section about the Product Backlog there is only mention of ‘sizing’ the items. The debate about whether or not using estimations is a strong one. And Scrum keeps all of its options open.
In conclusion
The Scrum Guide contains the definition of Scrum. This definition is written for the use of Scrum in all industries and domains. Scrum is no longer just for software development. With this update to the Scrum Guide, Scrum has become even more a lightweight framework and even less prescribed. It is intentionally incomplete. Ken Schwaber says: “just do it”. Making it sound very easy. The sentence ‘Scrum is easy to understand, but difficult to master’ is no longer in the Scrum Guide, but in reality this is still true. Since it is even more lightweight and even less prescriptive it can be difficult for new teams to start with Scrum. Existing teams can easily be swayed by the issues of the day. Therefore, it is more important now than ever to have a good Scrum Master or Agile Coach to guide their teams and to facilitate balance in the Sprint.
TMC Agile can help you with that. Are you planning to start with Scrum for your organization? Or perhaps you have already started but your teams can use a boost? Hire an experienced Scrum Master or Agile Coach from TMC Agile and give your team and your organization the Agile boost it needs!
