So what changed in the new Scrum Guide 2020?

The new Scrum Guide arrived yesterday and I was one of the many that joined Jeff Sutherland and Ken Schwaber’s virtual event to learn more. Some key changes that I thought are important

1. Introduction of the product goal

2. Emphasis on one team instead of a development team within a scrum team

3. More inclusive language for usage of Scrum beyond Software

4. A strong alignment of artifacts to product goal, sprint goal and Definition of Done

Has Scrum Changed?

There is no fundamental change to Scrum, the new scrum guide is fewer pages, less prescriptive and more inclusive to products beyond software. So let’s delve deeper in some of the key changes

• Introduction of the product goal: I always get asked in my Certified Scrum Master class, “I understand the scrum framework but where do we start? How do we build the product backlog?” The product goal represents a future state of the product and the product backlog emerges to realize the product goal. This is a key starting point because organizations have vision/mission statements, a product goal is part of the organization’s vision and serves as a north star for the product

• Emphasis on one team instead of a development team within a scrum team: The scrum team consists of one Scrum Master, One Product Owner and Developers (not no development team). A cohesive unit of professionals focused on the product goal. The total scrum is 10 or fewer people. By changing the development team to developers, the authors took away the concept of a sub-team within a team. The word “developers” could be used in context of developing hardware, a vaccine or a car and goes beyond a software product. This change is probably the biggest one that make the new scrum guide less prescriptive at many different levels.

• Inclusive language to indicate that Scrum goes beyond software products: Several new ideas such as removing the word “release” and making explicit that the sprint review is not a considered a gate to releasing value. Increments can be delivered at anytime, several times to the stakeholder during the sprint. I especially love the statement that there are various practices to forecast progress, burn-downs, burn-ups or cumulative flows. None of these replace the importance of empiricism.

• A strong alignment of artifacts to product goal, sprint goal and Definition of Done: Tying the product backlog as a means to achieve the product goal, the sprint backlog as a means to achieve the sprint goal and finally the idea that work cannot be considered part of the increment unless it meets the definition of done. In my experience several teams fail in scrum due to not having a product goal or clearly understanding or having a sprint goal or definition of done. I believe this strong alignment will bring a lot of clarity to ensure that these commitments are created and inspected and adapted at regular intervals.

Less prescriptive changes:

1. Eliminating the suggested three questions in Daily Scrum and more focused verbiage to increase cross collaboration

2. Keeping the language simple around sprint cancellations

3. Less specific on how many actionable improvements should be addressed as soon as possible coming out of a sprint retrospective

All in All

I really love the new Scrum Guide in its definition of Scrum as a lightweight framework to help generate value. As we dig deeper in this version, I am sure I will find more gems that I can share and enhance this write up. But if I had to pick on thing that emerged for me, it is “Adopting Scrum is not the goal, generating value is the goal”

Valerio and I will be talking about this in a live event on December 2nd at 3 pm EST. Register here to join our live zoom webinar

You can also download an audio copy from Michael Vizdo’s site at http://scrumguide.mvizdos.com/