Scrum Guide – definition of the rules of Scrum
Scrum is a framework that helps people, teams and organisations to create value through adaptive solutions for complex problems. It is used in product and software development and also in project management. The definition and rules of Scrum are laid down in the Scrum Guide.
The Scrum Guide is published by the two authors of Scrum Ken Schwaber and Jeff Sutherland. The current version was published on 18 November 2020. After the editions in 2010, 2011, 2013, 2016 and 2017 it is the 6th edition. The title is: “The Scrum Guide. The Definite Guide to Scrum: The Rules of the Game”. The hint “Definite Guide” could be an indicator that a lot of time will pass until a 7th edition. The guide is available in over 30 languages.¹
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.
Accountabilities instead of roles
In the Scrum Guide 2020 the term role is replaced by accountability. The accountabilities are divided into three groups:
- Scrum Master,
- Product Owner and
The idea behind this is that the names are not job descriptions, but rather a minimum of responsibilities that are necessary to carry out Scrum. This does not change the content of Scrum; roles have always been described by a number of responsibilities. The changes become clear when looking at the job titles “Scrum Master” or “Product Owner”. These will continue to be used in many organisations, but the job descriptions will be more comprehensive than the responsibilities described in the current Scrum Guide.
In addition, there will be a further adjustment in the context of accountabilities or roles: In the previous version of the Scrum Guide we spoke of a Development Team. From now on only developers are mentioned. Developers are the people in the Scrum Team who have committed themselves to creating every aspect of an increment in a sprint. In practice, this means that from now on not only software developers should feel addressed, but all those involved – for example, managers in the line, UX designers or marketing staff who are actively involved in a sprint.
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.
Commitments for artefacts
With the publication of the Scrum Guide 2020 commitments will be added for each artefact:
- For the Product Backlog the Product Goal,
- for the Sprint Backlog the Sprint Goal and
- for the Increment the Definition of Done.
The aim is to provide information through the respective commitment to the respective artefact in order to increase transparency and focus against which progress can be measured.
All commitments are obligatory, but the design is context-dependent. Responsibility for the commitments lies with the Product Owner for the Product Goal (he is also responsible for the Product Backlog), and with the Scrum Team for the Sprint Goal or the Definition of Done.
Commitment as a term continues to appear in the Scrum values (besides focus, openness, respect and courage).
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:
- Grooming (but Refinement is mentioned)
- Stand-up Meeting
- Definition of Ready
- Scrum of Scrums or scaling
- Story Points
- 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.
Impulse to discuss:
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?
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.
Here you will find additional information from our blog: