A brief look at the Scrum Guide 2020

Bernd

January 8, 2021

Overview

As you might have already noticed, the Scrum Guide has been updated in November 2020 after the last change made in 2017. Our team uses the Scrum Framework for developing NerdVision and we are frequently inspecting the way we work together in regard to this. We try to adapt where necessary with the overall goal to continuously improve and optimize our processes and increase business value. With the advent of this new version it was obviously time for us to look into the changes in the updated Scrum framework and review our way of work.

So as a brief reminder:

"Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems"

This is still true in 2020, in fact in my opinion this is even more true, because the new version has been significantly made shorter and more precise, allowing more flexibility by defining less rules. Let us have a look at the changes in the Scrum Guide 2020 in the following.

Changes

Less is More

As mentioned above the guide is now much shorter. By simply looking at the number of pages one can see that it has been condensed from 19 into 14 pages. This was possible by removing a lot of information that is not required in the Scrum Guide itself. Some examples of this are

  • All references to IT related topics have been removed to make it more obvious that the Scrum Guide can be applied to address any complex work, not only software development (okay, it still uses the word "Developer" for which most people - at least in Germany - think about Software Developers)
  • The well known example of the three questions to ask in the Daily Scrum
  • When and how work should be estimated (for the nitpickers: the word "estimate" does not exist any more in comparison to 9 occurrences in the 2017 Scrum Guide)
  • The reasons why and how the Sprint-Retrospective should be done
  • How much time should spent for backlog-refinement
  • Which attributes a Product Backlog Item (PBI) should have

One Team to do it all

The Scrum Team is now defined as a team made of the Product Owner, the Scrum Master and the Developers. There are no sub teams or further hierarchies. This team is self-managing (in the 2017 Scrum Guide the term self-organised was used) which means it is more empowered. A team is self-managing when it internally decides who does what, when and how.

"The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint."

Product Goal

To support the Scrum Team in focusing on a larger and value-creating goal the Scrum Guide 2020 introduced the Product Goal:

"The Product Goal describes a future state of the product which can serve as a target for the Scrum Team
to plan against."

The Product Goal provides the Scrum Team and stakeholders with a context and direction for the work to be done.

Commitments for the Artifacts

With the advent of the Scrum Guide 2020 the Sprint Goal and the Definition of Done now finally have been included. They represent the commitment to an artifact. Including the Product Goal mentioned above these commitments look like the following:

  • The Sprint Goal is the commitment for the Sprint Backlog
  • The Definition of Done is the commitment for the Increment
  • The Product Goal is the commitment for the Product Backlog

These commitments help to provide clarity about the purpose and value of the artifact. They improve transparency and provide a way to measure progress against the artefact.

The Why in the Sprint Planning

The Sprint Planning now also considers the "why" of the sprint. In the Sprint Planning the Scrum Team answers the questions

  • What needs to be done?
  • How will the work be done?

and, with the changes in the Scrum Guide 2020, now also

  • Why should it be done? (What is the business value)?

The last question is reflected in the Sprint Goal.

Multiple Product Increments

One last notable change is that a Sprint now can have multiple Product Increments and an Increment may be delivered also during the Sprint. The Sprint Review should not be considered a gate to releasing value:

"Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the
Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders
prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value."


Conclusion

In my opinion, the changes in the new Scrum Guide 2020 are a real improvement. Doing away with everything that is not absolutely necessary and focusing on the essential things makes it much easier to deal with Scrum. As a team, this also confirms our current way of working together. We already act as a self-managing team.

Bernd

Bernd

Working as a software engineer for many years mostly in the JVM environment. Skilled in Scrum and Agile practices, currently scrum master of nerd.vision.