Many articles tend to look only at the changes to the Scrum Guide (SG) 2020, but I prefer to view it from the perspective of quality and test.

SG2020 is the sixth version to be produced since the initial creation of the 2010 edition. Revisions were produced in 2011, 2013, 2016, 2017 and the latest in 2020.

To cater to a wider audience, it has been reduced from 19 pages to 13. As Scrum has been founded on empiricism and lean thinking, we can expect that in the future, SG will continue to change in order to be more flexible and focused on tying the product to its business value.

The changes between SG2017 and 2020 are:

SG2020 is now less prescriptive

Prescriptive language has been softened or removed, making the focus even less on "how" and even more on "why" and "what". Here are some examples from a testing perspective:

Example: Removal of Daily Scrum questions

SG2020 now encourages experimentation to adjust the Daily Scrum to the Scrum Team’s needs, as more mature Agile teams found the three-question method to be limiting. Experienced Planit practitioners have already implemented such activities and found the Daily Scrum to be more efficient to discuss incomplete tasks in the Sprint taskboard, and collaborate on their progress (walk the board). It makes it easier for the whole Scrum Team to understand how close (or far) the team is from the Sprint Goal and take corrective action swiftly.

Example: Change from "servant leader" to "true leaders who serve..."

A common observation is that one of the biggest challenges in the industry is servant leaders who don’t lead. Agile delivery is adopting Quality Assistance is a good practice. The Quality Assistant leads the team in understanding their responsibilities with regards to quality activities and engenders a shared ownership of quality to deliver a product that delights the customer.

Practitioners at Planit are leading the way in putting quality front and centre with their Agile teams. They are coaching, mentoring, and training the team to make the whole team responsibility for quality, and “shift left” activities to build quality in as part of preventive activities rather than waiting to detect low levels of quality or defects.

Example: Removal of Product Owner deciding to release the Increment

Our practitioners have found that the Sprint Review works as a gate to release value in less mature Agile teams, which is in direct conflict with the Scrum Guide. With one practitioner overhearing a tester comment that, “if the development team decides to release the increment, you are showing that the development team is the boss”, which reinforces the notion that many Scrum teams may be nervous having this accountability. Therefore, the whole team needs to take accountability for the fitness and quality of the product.

Example: Softened language around Sprint Retrospective improvements, etc.

In an interview for the SG2020 with the authors, the interviewee mentioned that, “Scrum encourages teams to improve. The retrospective event provides them with time to look at how they are working and propose improvements. But by including a process improvement every Sprint, we force the Scrum team to prioritise improvements over other forms of value. This might not be the right choice for the product owner working with the rest of the Scrum team - we felt that this was too prescriptive. However, we continue to believe this is a great practice and suggest all Scrum teams consider it - it just doesn’t need to be so prescriptive in the Scrum Guide.”

Our practitioners have observed teams try to take on too many improvement activities in the next Sprint. A better approach, which they have adopted, is to agree on a single critical improvement for inclusion in the next Sprint.

If it is agreed the improvement would be too big for inclusion in the next Sprint, then the team approaches it as they would for an Epic (break it down into smaller chunks). This means that improvements are being made continuously, but ones that the team are able to absorb to become good habits.

In addition, the retrospective should celebrate successes, but this is often forgotten, which can affect team morale. Go out for lunch or bring in a plate to share during morning tea!

One team focused on one product

The goal is to eliminate the concept of a separate team, as happens with the three roles and the development team, and instead have one team focused on one product. The separate development team could create a “us vs. them” mindset between the product owner, the Scrum Master, and developers.

By removing the development team, we have one Scrum team focused on the same objective. This will improve the cohesiveness of the team, with many Planit Agile practitioners experiencing the legacy of “development” terminology being solely related to developers. The “Scrum team” is a more appropriate naming convention, as it encourages inclusion and a sense of belonging to the team. It also re-inforces that all team members are of equal value, they just have different roles, skills and competencies including quality/test knowledge.

Our Agile practitioners are skilled in offering the Quality Assistance approach as a means of building quality in rather than testing it out. From quality assurance activities, such as requirement and user story reviews, to promote a common understanding, removal of ambiguities, and ensuring testability, through to participating in “3 amigos” discussions, the practitioners are moving away from being quality gatekeepers, to instead sharing their knowledge of test-and quality specific skills with the Scrum team.

This includes the use of testing techniques, static testing, and assessing product risks. If the whole team is working together on the one product, this helps to deliver the best quality to end customers – a goal that every organisation wants to achieve.

Introduction of the Product Goal

The Product Goal provides context to the Product Backlog. It can be thought of as the ‘why’ the Product Backlog exists and the Scrum team is doing the work.

A good Product Goal is something to strive for, and is measurable and visible to the Scrum Team and their stakeholders. What is important is that the Scrum team agrees on a single Product Goal that provides clarity and context for the work, and is easy for the Scrum team and stakeholders to understand.

Applying the “why” question to every element and activity in the Scrum delivery is another good change. Emphasising the Product Goal moves the responsibility of the Scrum team from the process of building the product itself to adding to its value. It most definitely improves the relationship between the Scrum team and business, and makes every Scrum team member more aware of the common objective.

One area where our practitioners have added value is through collaboration with design teams to produce prototypes as a visual representation of where the user stories are leading. They have also conducted product risk workshops, which have helped to identify the product risks and which of these testing can help to mitigate.

Our practitioners are customer-focused and highly skilled in contributing to customer-centric design. By acting as advocates for the customer, they understand the quality attributes that are important to the customer.

A home for the Sprint Goal, Definition of Done, and Product Goal

Each Scrum artifact now contains a commitment, and each commitment enhances transparency and focus against which progress can be measured. For the Product Backlog, it is the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done (DoD).

There is a heightened emphasis in SG2020 on the three commitments - Product Goal, Sprint Goal, and DoD make it more clear how cohesion between autonomous teams and professionals is created through a commitment to goals, and not to specific tasks. Our Agile practitioners have observed less mature Agile teams completely remove the DoD for a given Sprint at the request of senior management, and other teams that created a template for the DoD and never revisited the contents.

DoD is a living artefact and should not be static. As part of the sprint retrospective, the Scrum team should be discussing process improvements and be checking whether the DoD should be updated based on the team’s maturity level. E.g. the team now utilises the INVEST method for reviewing user stories.

The DoD and Definition of Ready (DoR) are critical artifacts that drive building quality in and shift left activities. They are important in increasing those fast feedback loops that accelerate quality.

Self–managing over self–organising

The SG now uses the term self-managing to emphasise that Scrum teams choose who, how and what to work on, whereas the previous SG referred to development teams as self-organising, choosing who and how to work.

In less mature Agile teams, our practitioners have observed a self-organising development team doing whatever they wanted and not meeting the commitments such as the Sprint goal. By using the term self-managing, the aim is to stop teams from weaponising self-organisation as a tool to avoid any commitments. Instead, the team self-manages to deliver its commitments to meet the goals.

In more mature teams, our practitioners have observed the Scrum team make the decision to remove larger stories and replace them with smaller ones, and then decide what to work on. At the same time, less mature teams often heavily rely on the product owner and Scrum Master deciding what the team works on.

Given the whole team’s responsibility for quality, quality assistance activities help the team manage their contribution to quality activities.

Three Sprint planning topics

The new topic "why" is introduced to put an emphasis on the Sprint Goal, answering why a Scrum team does a Sprint. Having a Sprint Goal provides a visible focus on how the Sprint is adding value.

Our practitioners have observed less mature Agile teams which do not have a Sprint goal - instead, a one line objective exists on each user story. Rather than focus on a single Sprint goal, the less mature teams attempt multiple initiatives within a single Sprint.

This is often at the cost of quality as they rush to complete stories without allowing enough time to test, or not doing other quality activities such as skipping product refinement sessions involving the whole team. If team members rush to complete their own individual tasks rather than understand if one element is not done, then the whole team has failed. This change will help with collaboration and really becoming a cross skilled team.

Overall simplification of language for a wider audience

Redundant or overly complex language and IT-specific language has been removed to make SG more accessible to teams doing complex work outside of IT. Our practitioners have experienced the use of Scrum across domains perhaps not traditionally thought of as IT,such as marketing and construction.

The fact that the word “testing” no longer appears in SG2020 is part of this change, which may cause new members of less mature Agile teams to take longer to understand where the role of testing is catered for within Scrum. In fact testing and more widely quality responsibilities need to be completed by all team members and is it no longer the role of the tester to be the “quality police”.

Clear goals for better outcomes

By its very nature, complex work is deeply unpredictable.

The Scrum framework has always been about enabling the people who do the work to take control of that work. This expands the potential creativity, expertise, and experience to everyone who is doing the work.

One way to create cohesion in high-autonomy environments is through clear, singular goals that give direction without dictating the work in detail — that is up to the experience of professionals.