On 18 November 2020 a new version of the Scrum Guide was published. This article shows which changes have been made compared to the previous version from 2017.
The new version of the Scrum Guide (PDF version) has been shortened from 19 to 14 pages, mainly because redundant statements have been removed from the Scrum Guide and complex content has been simplified. In addition, there are no longer any clear guidelines or action steps regarding the Scrum ceremonies. The authors emphasize that this is a conscious step and that Scrum is based on the collected intelligence of the people who want to use Scrum. This is an implied request to the users of Scrum to question the framework and also to adapt it pragmatically according to the three pillars: transparency, inspection and adaptation. This simplification approach is rounded off by the linguistic loosening within the definition of Scrum theory. The authors refer to “observations” instead of concrete “knowledge”. (Empiricism asserts that knowledge comes from experience and making decisions based on what is observed)
In general, the new version emphasised that Scrum is no longer a process framework but a lightweight framework that is designed to help solve complex problems. This also changed, as the previous version spoke of complex products. A further breaking up of the Scrum framework was done by deleting the areas of application of Scrum. The 2017 version dedicated a complete subchapter “Uses of Scrum” to the field of application of Scrum, which is no longer to be found in the new 2020 version. There the authors tried to show the diversity of Scrum, but at the same time they did not do justice to the framework, because the definition of the areas of application is by definition a limitation of it.
Another change is that the authors no longer speak of a product vision but, in simplified terms, of a product goal. This becomes especially relevant for the artefacts that are highlighted at the end of the article.
Another novel idea is the inclusion of the LEAN concept within the Scrum framework, which in my opinion also complements the concept of Scrum very well. Within the framework of LEAN, so-called WASTE is identified and finally turned off so that one can focus on the essential. This is congruent with the tenth point of the Agile Manifesto which says: “Simplicity–the art of maximizing the amount of work not done–is essential”, which in this context also addresses a focus on the essential.
Now that we have compared the fundamental changes of the Scrum Guide versions of 2017 and 2020, I would like to go into more detail about the changes regarding the pillars of Scrum, the roles, ceremonies and artifacts.
Pillars of Scrum
The three pillars of Scrum remain unchanged: inspection, transparency and adaptation. The change in this respect is that inspection no longer refers specifically to the sprint goal, but more generally to the mutually agreed goal. Another useful adaptation of the guide is also the establishment of references between the three pillars. The Scrum Guide provides the following three highlighted statements in this respect:
- Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.
- Transparency enables inspection. Inspection without transparency is misleading and wasteful.
- Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.
Scrum Team
The chapter on the Scrum Team and the roles it contains has been significantly revised in the new version. These start with the team composition.
The new Scrum Guide now speaks of the Product Owner, Scrum Master and Developers. There is no longer a development team by definition. This was an intended change to create a better team feeling and a better team framework. Often the structure of the Scrum Team as Product Owner, Scrum Master and Development Teams created a special position of the first two roles. In the sense of Scrum, the focus is on achieving the product goal and this can only be achieved in close and efficient cooperation between all roles. A special position or further differentiation was therefore rather counterproductive in this sense. The authors also emphasise that there are no hierarchies and so-called sub-teams. This is possibly also the reason why the role of the developers in the new Scrum Guide was defined in the first place before the product owner and Scrum master.
An equally important adjustment of the Scrum Guide is the understanding and increased empowerment of the Scrum Team regarding the way they work. This should not only work in a self-organising way, which means determining who and how work is done, but also in a self-leading way, which means that the team is also able to determine independently what is to be worked on.
Where the new version has incorporated one or two cuts in terms of proposals, it also added a proposal for a scaled approach, which is very pragmatic. Should the Scrum team become too large, it should be split up, but with the same product in focus. According to the new version, this also suggests that this team should have the same product goal, product backlog, as well as product owner.
Another change is that there are no longer clear guidelines for team size. The guide only states that the team should be as small as necessary and as large as reasonable to achieve the product goal. This is due to the fact that very large teams entail an increased organisational effort in terms of coordination and communication.
Roles in Scrum
Probably the most profound change relates to the definition of roles. The Scrum Guide no longer advocates a “responsbility” for the tasks to be done, but makes the roles “accountable”. I will now show which changes have occurred in the respective roles:
Developer
Besides the change of name from the development team to developers, there were other changes. These changes relate to the strengthening of the sense of duty of each individual. This is reflected in the fact that the developers are “accountable” for the following tasks in order to be able to provide a useful part of the increment during each sprint.
- Creating a plan for the sprint, the sprint backlog;
- Delivering quality by adhering to a definition of what has been done;
- Adjust your plan to the sprint goal every day; and
- To hold each other accountable as professionals.
Product Owner
As explained at the beginning, the product objective was given priority. The product target replaces the well-known product vision. The development and explicit communication of the product goal remains the responsibility of the product owner.
In addition, the position of the product owner within the organisation towards the stakeholders has been strengthened. If stakeholders express the wish to have new product-related changes included in the backlog, it is no longer sufficient to address these issues, which implies that these issues are definitely included and that the question of “when” the implementation will take place, but that the product owner should be convinced to include these issues in the product backlog.
Another point that shows that the Scrum Guide does not give clear guidelines anymore is reflected in the possibility of the Product Owner task delegation. The Scrum Guide no longer stipulates that tasks can only be delegated to the Scrum Master or developer. However, it is important that the Product Owner is not only “responsible, but now also accountable” for these tasks.
Scrum Master
The role of the Scrum Master has been extended in terms of organisational accountability. The new Scrum Guide emphasizes more and more that the Scrum Master serves not only the team but always the whole organization by multiplying the theoretical as well as practical knowledge of Scrum within the team and the organization. The Scrum Master activities have been supplemented by those of the trainer and consultant based on the previous leading and coaching skills. In this function a new activity was also added, namely the reduction of concrete barriers between stakeholders and Scrum teams.
A fact that surprises me personally is the deletion of the following activity:
“Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization”.
In my opinion it makes a lot of sense to continue working and exchanging ideas with other Scrum Masters to further the overall goal of agile transformation of the organization. Why this point has been deleted in the new version or why my interpretation is possibly wrong is still open.
Furthermore the role of the facilitator as Scrum Master was challenged by the fact that the Scrum Guide no longer focuses on the facilitator explicitly for the productivity as well as the achievement of the goals of the Scrum ceremonies, but always on the whole team.
Scrum Ceremonies
Based on this, I would now like to talk about the changes within the Scrum ceremonies.
As already emphasized in the general part, the Scrum Guide here is more open and does not give clear instructions for the individual ceremonies anymore.
Sprint
The description of the Sprint is largely unchanged in terms of content. The authors emphasised once again that the Sprint must focus on a development towards achieving the product goal. They also made sure that the Backlog Refinement is part of the active sprint, even if it is not classified as a separate ceremony. I think this is a very good addition, as the question of when the Backlog Refinement should take place was often raised.
Also the subchapter “Cancelling a Sprint” was deleted and only covered with the following statement: “A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint”. There are no longer clear instructions for action as in the 2017 version.
Daily
The revised version no longer gives any instructions as to how it should be carried out. The Daily should continue to be time-boxed to finish in 15 minutes, helping to achieve the sprint goal and providing transparency regarding the next working day. In the 2017 version, the proposal was prepared to answer the following three questions:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
This proposal has been completely deleted. The roles of Product Owner and Scrum Master have also been sharpened in relation to the Daily. If the Product Owner or Scrum Master is working on an item from the Sprintbacklog, they take part in this ceremony as Developer.
Sprint Planning
The two-part sprint planning: planning the “what” and planning the “how” from the 2017 Scrum Guide has now been supplemented by a third dimension. This dimension aims at the general value of the Sprint and precedes the other two dimensions.
In summary, this overall sprint planning includes the following three dimensions:
- Topic One: Why is this Sprint valuable?
- Topic Two: What can be Done this Sprint?
- Topic Three: How will the chosen work get done?
Sprint Review
While the subchapter of the Sprint Review in the 2017 version still contained detailed suggestions on how to proceed or how to conduct the ceremony, the 2020 version reduced itself to emphasising the meaning of the Sprint Review. The sprint review is intended to inspect the work done and evaluate future work. This ceremony should not be limited to a mere presentation, but rather be understood as a working session.
Scrum Artefacts
After the roles and ceremonies have been illuminated, I will conclude by discussing the Scrum artefacts.
What is new is that the artefacts are now placed in relation to each other or to the goals.
Each artefact contains a commitment to ensure that it provides information that increases the transparency and focus against which progress can be measured:
- For the product backlog, it is the product target.
For the Sprint Backlog, it is the sprint target.
For the Increment, it is the Definition of Done.
These commitments exist to strengthen the empiricism and Scrum values for the Scrum team and its stakeholders
If you have any further questions or comments regarding the new version of the Scrum Guide, please feel free to contact us!