What is the Scrum Guide?

The content of the Scrum Guide

The Scrum Guide 2020 includes the following contents:

• purpose of the document,
• Scrum definition, theory and values,
• Scrum Team with Developers, Product Owner and Scrum Master,
• Scrum events with Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective,
• Scrum artefacts with Product bBacklog, Sprint Backlog and Increment as well as corresponding commitments in the form of Product Goal, Sprint Goal and Definition of Done,
• seclaration at the end including statements like acknowledgements and history of the Scrum Guide².

It is interesting that the guide itself contains an assessment of Scrum. According to this the two authors understand Scrum as a lightweight framework and not as a method. The Scrum Guide itself is not an instruction how to implement Scrum, but “only” a description of the framework. Different methods, processes or techniques can be used within the framework. Each element described in the guide serves a specific purpose that is essential for the overall value and results achieved with Scrum.

Simplifications in the Scrum Guide 2020

The Scrum Guide 2020 is slimmer than its predecessor: the current version has 13 pages, the previous version had 20. It is emphasised several times that users should maintain a smart and intelligent handling of Scrum, based on the still existing pillars of transparency, inspection and adaptation. The context is essential for the application of the framework, so that the authors have decided to leave out various descriptive elements and explanations:

• In general, events are described in less detail. For example, in Daily Scrum the three questions commonly used in practice are no longer named and there is no indication that an identified process improvement should be included in the Sprint Backlog to ensure continuous improvement. Also, the very comprehensive description of the elements of a Sprint Review or the detailed reasons why a Retrospective is conducted no longer exist.
• Notes such as “Refinement should not take up more than 10% of the development team’s capacity”, “Scrum is lightweight, easy to understand but difficult to master” or “lack of product understanding is an impediment” have been omitted.
• General explanations were omitted. Even though requirements will continue to change and the progress of a development needs to be monitored, there is no reference to this in the Scrum Guide.

These simplifications are not about declaring lived and meaningful practices as useless. They have a different goal: because the Scrum Guide is less prescriptive, there are fewer “obligatory” elements. Consequently, the framework becomes more user-friendly and allows practitioners to use the elements and practices that make sense in their context. So in a way there is less coercion and more freedom. And certainly for many organisations it will continue to make sense in the future to structure the Daily Scrum with three uniform questions and a focus on the Sprint Goal.

Innovations in the Scrum Guide 2020

Of course the Scrum Guide 2020 does not omit or simplify the information. There are also some innovations:

• the use of accountabilities instead of roles,
• the definition of a product goal,
• the emphasis on commitment to artefacts,
• and self-management replaces self-organisation.

Product Goal

New in the Scrum Guide 2020 is the Product Goal. As the equivalent of the Sprint Goal, which sets the direction for the Sprint Backlog, the Product Goal provides the scope for the Product Backlog. It can be understood as an answer to a “Why”: “Why are we doing all of this work?”. It gives direction to the Scrum team and stakeholders, provides a context and a purpose.

The product goal, which should be made transparent in the Product Backlog, is desirable for the Scrum Team and must be measurable. The concrete design, but also the measurement is of course context-dependent. In a certain way there is an interaction between Product Backlog and Product Goal: The Product Goal helps to develop the Product Backlog. And the development of the Product Backlog can have an impact on the Product Goal. So this can also develop over time.

And what is the difference between Product Goal and a vision? In the 2017 version of the Scrum Guide it said: “The increment is a step towards a vision or a goal”.In the current edition, on the other hand, it says: “An Increment is a concrete stepping stone toward the Product Goal.”. Since Scrum continues to encourage teams to make step-by-step progress towards a goal, the difference is rather marginal. In practice, it could be that a vision statement describes the product goal in detail, or that the product goal is a first step towards a larger vision. In short, the use of the terms vision, mission, strategy and now product goal depends on the context.

Self-management instead of self-organisation

In common practice, the terms self-organisation and self-management are often used synonymously. So why does self-management replace self-organisation in the Scrum Guide? The aim is to focus even more on the Scrum Team. It is responsible for all product-related activities, e.g. for cooperation with stakeholders, conducting experiments, developing, operating or maintaining a product. In order for the Scrum Team to be able to do this, it must be empowered by the organisation to manage itself. This self-management goes beyond self-organisation, especially as it not only addresses the organisation of one’s own work, but also the ability to decide who within the team does what, when and how.

By the way, the Scrum Guide does not explicitly comment on managers in organisations. These could continue to act outside the Scrum Team to support it. They could also participate in the creation of an increment as part of the Scrum Team. As a general rule, the Scrum Guide continues to negate any interference from management “from outside” with negative influence on the Sprint Goal and/or the Product Goal. For Scrum to work, the Scrum Team must have the freedom to take responsibility for the work to be done, i.e. for who, what, when and how. Self management is therefore the appropriate term.

Clarifications from the Scrum Guide 2017

In addition to the simplifications and innovations, the current Scrum Guide also contains statements on aspects that were clarified in the 2017 version:

• Even though Scrum has its roots in software development, the elements and rules are generally suitable for any product or service development due to their iterative, incremental approach. This is reinforced in the current edition by the explicit renunciation of descriptive explanations from the context of software development.
• It remains the task of the Scrum Master to implement Scrum according to the Scrum Guide. In addition, he supports the Scrum Team, the Product Owner and also the entire organisation.
• All meetings work with timeboxes. Of course, these may still be understood as “maximum” timeboxes, so that corresponding events can be ended even before a timebox expires.
• The Daily Scrum is oriented towards the sprint goal even if the three “usual” questions are no longer explicitly mentioned.
• The Sprint Review is still oriented towards the sprint goal. The Scrum team presents the results to the most important stakeholders and the progress towards the product goal is discussed. As usual, it is a “working meeting” and not a release presentation.

“Missing” terms in the Scrum Guide

In the past, there have always been voices that say, “What is not in the Scrum Guide is not Scrum! In fact, this was a relatively impractical argument; many elements that were used in numerous Scrum projects and developments were not in the Scrum Guide.

Due to the simplifications the Scrum Guide has “shrunk” from 20 to 13 pages. It is explicitly mentioned that the Scrum Guide is “purposefully incomplete” and only defines the parts that are necessary for the implementation of the Scrum theory. So it does not matter that the following terms are not mentioned:

• Velocity
• Grooming (but Refinement is mentioned)
• Stand-up Meeting
• Definition of Ready
• Scrum of Scrums or scaling
• Story Points
• Traceability
• Vegas Rule
• …

And by the way: Even though Scrum is the most widely used framework in the agile context, the terms “agile”, “agility” or transformation do not appear.

According to the Scrum Guide 2020 the Scrum theory is based on empiricism and lean thinking. In the 2017 version there was no mention of Lean Thinking. Doesn’t Lean Thinking include much more than just simplification?

Notes:

[1] Here you can download the Scrum Guide in English. And here in German.
[2] Here you can find a description of the different editions including the changes.

As a recommendation the Scrum team size is given as 10. Since both Product Owner and Scrum Master are assigned to the Scrum Team, 8 developers “remain” in the team. In the old Scrum Guide there were still 9.

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.

Here you will find additional information from our t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.