The new SCRUM Guide

The current SCRUM Guide 2020 was published in November, around three years after the last version. There are some significant changes, even though Scrum is still Scrum.

At first glance, it is noticeable that the language and many terms have changed. The new Scrum Guide tries to simplify the language and to weaken the previously strong references to the IT industry. The guide is becoming more generic and thus takes into account developments in practice.

It is also noticeable that the guide has become leaner, a number of detailed rules and instructions have been omitted, the guide is limited to the description of the framework. This does not mean that the details from the previous version (2017) no longer make sense. For example, if you find the three guiding questions about the structure of the Daily Scrum helpful, then keep using them. The Scrum Guide just no longer goes into this level of detail and wants to be less prescriptive.

I would like to highlight some changes as they make a clear difference. First of all, there is the view of the Scrum Team.

The new Scrum Team

In the new Scrum Guide there is only one team, the Scrum Team. The developers are no longer referred to as a team within a team. Apparently, this has led to confusion. Now it is a team that, sprint for sprint as a whole, bears the responsibility for implementation (responsibility) for all its activities and accountability for useful and valuable increments.

The different responsibilities of Product Owner, Developer and Scrum Master remain within the Scrum Team. However, they are no longer called roles, but rather accountabilities.

Product Goal, Sprint Goal and Definition of Done

The sprint goal is well known, i.e. the goal that is to be achieved in a sprint: what the processing of the individual items should result in, i.e. the “why”. The sprint goal should now be recorded in the sprint backlog and always be visible to everyone.

The same is now also available for the Product Backlog, the Product Goal. That is a description of the why of the product, because the product is only the instrument for creating value. This should make the orientation of the backlog items clearer because it is fixed and transparent in the Product backlog.

As a third “commitment”, the definition of done is basically already known. This is the unambiguous description of the condition of the increments, which makes them acceptable: It is thus the clear orientation point and quality criterion for the individual increments. The definition of done clearly belongs to the increments.

Spint Planning

As described in the previous section, the emphasis on “why” is taken much more seriously and is given more importance. Items can also be processed in Scrum without perspective. A stop should be put in place, precisely because many teams find it difficult to define a sprint goal.

Sprint planning now consists of three topics:

  1. Why is this sprint valuable? This is about the value by which the product should grow and the sprint goal.
  2. What can be completed in this sprint? Now it's about the selection of the items and the creation of the sprint backlogs
  3. How is the selected work done? Now the selected work is scheduled to create the increments that match the Definition of Done. This plan makes the sprint backlog complete.

All in all, there are some very stimulating changes that respond to real-world challenges. The concrete application in operational practice will show how they prove themselves in practice.