Scrum Guide – introduction

While Scrum had its beginnings in the ’90s, the first version of the Scrum Guide only appeared in 2010. Over the years, it’s been getting increasingly popular, especially with the IT crowd. It continues to adapt to the ever-changing reality and the needs of people. The year 2020 saw the release of the 5th version of Scrum Guide. What has changed since then? Let’s take a closer look at a framework that has earned its reputation of being easy to learn and hard to master through the latest iteration of the Scrum Guide.

Before we proceed, keep in mind – if you have never had anything to do with Scrum and the vocabulary below seems foreign to you, read our previous Scrum article for beginners first. They will help you understand the role of Scrum in software development.

What’s new in Scrum Guide?

1. Product Goal

An entirely new concept introduced in Scrum Guide 2020. Until now, the Scrum Team only got to define one goal – the Sprint Goal.

Introducing this new goal brings the Scrum Team (more about it later) even closer to the business. It allows you to define a bigger goal you want to achieve by completing the smaller goals of the Sprint. It gives a wider perspective and tells us how much you still need to do to get to the final goal.

Just like it is the case with the Sprint Goal, there should only be one Product Goal defined at any given moment. Only once it is completed, you can move to the next one.

The Product Goal is the long-term objective of the Scrum Team. They must fulfil (or abandon) one objective before taking on the next.

Adding a Product Goal also takes care of the issue of Scrum Artifacts. Each one of them has a commitment – for Increment, it’s Definition of Done (DoD); for Sprint Backlog, it’s Sprint Goal and Product Backlog corresponds with Product Goal.

2. The three questions of Sprint Planning: Why, What, How?

The introduction of Product Goal and all the implications of it are a big nod towards the world of business analysis. The truth is that business analysts have been trying to get the Product Owner (PO) and other Scrum team members to answer the why question for years. Up till now, the Sprints were more about What, while developers handled the How side of things. With Why, the Scrum process and the Sprint Planning is going to be very different.

To make the Why question separate seems like a natural step. It’s been in a way a part of Scrum for years during the process of gathering requirements – a technique known as the 5 Whys. Those who write User Stories in order to describe requirements also know that the Why question is an essential part of the description because it helps you understand the benefit to be achieved by the user in the story. You can focus on who it is for, what should be done and what can be achieved with it.

The Why questions also make it easier for developers to understand the business value of a given task, feature or User Story. It helps fulfil one of the 7 principles of Agile Business Analysis, that is See the whole. You can read more about the relationship between business needs and User Stories here.

Another important aspect of the Why questions is that it forces the PO to implement the analyze to determine what is valuable process before an element can be added to the product Backlog. It protects the product Backlog from becoming a wish-list of tasks that will never be completed. Again, it’s an answer to the needs of Business Analysis. It’s an approach mentioned by IIBA in Agile Business Analysis among others. It’s not an exaggeration to say that with the new version of the Scrum Guide, the connection and understanding between Scrum and the Business will be better than ever.

What’s changed?

1. Scrum Guide slimmed down

If you are familiar with the previous version of Scrum Guide, you will immediately notice how much smaller Scrum got with the new release. It’s now just 13 pages instead of 19 – a reduction of over 30%. Why is that? Primarily, some redundant and complex instructions, as well as questions in Daily Scrum, were dropped. The section on cancelling a Sprint in the new Scrum Guide is also much shorter now. Before it had an entire subsection dedicated to it – now it’s just literally two sentences.

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

The language itself has become less normative. The new Scrum framework is more flexible and encourages adjusting it to your own needs. You could say that the writers of the new Scrum Guide aimed at minimizing the amount of content and maximizing the key values in the Scrum development process.

2. No questions during Daily Scrum

A big change if you ask us. The three questions method (you can read more about it in this Daily Scrum tutorial) hasn’t always produced good results. In our experience, it’s often much more efficient to use the Daily Scrum to go over all tasks in Sprint Backlog and discuss their progress. It makes it easier to understand how close (or far) the team is from the Sprint Goal. No strict form of the new Daily Scrum encourages experimentation to adjust the Daily Scrum to your needs.

Nevertheless, the Scrum Guide emphasizes that you should follow the progress in achieving the Sprint Goal at all times, not just during the Daily Scrum. Especially when there are some clear danger signals. Once observed by a team member, they should be relayed immediately. 

3. Emphasis on Definition of Done

As we already mentioned, the Definition of Done is now a commitment of the Increment. What it means is that the Definition of Done serves as a way of ensuring that the quality of Increment delivered is sufficient. The Definition of Done in the new Scrum Guide makes it easier for everyone to understand what exactly was done. It’s essential so that all elements of the Sprint Backlog conformed to the Definition of Done. There are no exceptions to this rule. Here a couple of examples:

• Code review is done;

• Functionality is implemented and tested;

• Test scenarios for functionality are prepared;

• The task is in the DONE column;
• Code is deployed and available in the staging environment.

If the DoD is standardized for the whole organization, you should use it in every product. It improves transparency and makes it easier to work on various products simultaneously. It shows the maturity of an organization and its understanding of the Scrum approach. This maturity and understanding can help you make better products.

4. Emphasis on Sprint Goal

According to the Scrum Guide, Sprints are the heartbeat of Scrum, where ideas are turned into value. It couldn’t have been said better. However, before your Sprint can produce value and bring you closer to the Product Goal, you need to define your Sprint Goal. 

You should do it during the very first opening meeting for a new Sprint – the Sprint planning. The Scrum team must use it to answer the question: Why is this Sprint valuable? To answer this question, you need a process defined by the Scrum Guide as follows: The Product Owner proposes how the product could increase its value and utility in the current Sprint. Subsequently, the whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. This Sprint Goal should be defined at the end of the Planning meeting.

Teams that adhere to these rules are able to prioritize tasks in the Sprint very efficiently. What’s noteworthy here is that when a Sprint Goal becomes untenable or out-of-date, it can justify cancelling the entire Sprint.

5. New naming conventions for the Team

The latest Scrum Guide made some significant changes to the naming convention and division of roles in the team. Dev Team is now replaced with Scrum Team. The latter term now includes one Scrum Master, one Product Owner and Developers. The concept of team members remains the same. It’s still recommended that they consist of no more than 10 members. They should also be cross-functional (beable to complete tasks given to them without external help) and self-managing (be able to decide on the responsibilities within a team independently.

Another new term is Developers, which refers to the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The Scrum Guide doesn’t specify the qualities of the Developer, except that they should be broad and will vary with the domain of work – a nod to the fact that Scrum can be applied to many activities other than software development.

6. Team responsibility

The Scrum Guide is particular about describing the responsibilities of each role it defines. The authors divided the responsibilities into two categories: responsible and accountable. The Guide states that the Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. In addition: the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. 

As we already pointed out, the Scrum Team now has three roles. Each of them got clear responsibility guidelines. In accordance with those, Developers are responsible for:

• Creating a plan for the Sprint, the Sprint Backlog; 

• Instilling quality by adhering to a Definition of Done; 

• Adapting their plan each day toward the Sprint Goal; and,
• Holding each other accountable as professionals.

The Product Owner’s responsibilities revolve mostly around the Product Backlog and the many ways the Product Backlog impacts the Product Goal. They are accountable for maximizing the value of the product resulting from the work of the Scrum Team and for effective Product Backlog items management, which includes:

• Developing and explicitly communicating the Product Goal; 

• Creating and clearly communicating Product Backlog items; 

• Ordering Product Backlog items; and, 

• Ensuring that the Product Backlog is transparent, visible and understood

Last but not least, the Scrum Master is responsible for establishing Scrum as defined in the Scrum Guide and the Scrum Team’s effectiveness.

And that’s it for the main character? Well, while the Guide now only defines two responsibilities for the Scrum Master, this role is still key for the Scrum process. Why?

7. Scrum Master more essential than ever

The new Scrum Guide clearly states that there is no Scrum without the Scrum Master.

Scrum requires a Scrum Master to foster an environment

It doesn’t mean that companies should hire a dedicated Scrum Masters. Instead, a stakeholder should be chosen to fulfil the role and take on responsibilities assigned to the Scrum Master. 

One of the final paragraphs of the Scrum Guide lays out exactly how to implement all these rules:

The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Scrum Guide 2020 – summary

Even though Scrum has existed for over 25 years now, it has not stopped adapting to the changing world. The new Scrum Guide is proof of that. Among many changes introduced in the Scrum Guide, you can also observe that Scrum is now more open than ever to industries other than IT, where the Agile approach to project management has been a staple for quite some time. The definition of Scrum in the new version of the Scrum Guide is now more inclusive than ever before. We can expect great team variety and the expansion of Scrum values beyond software.

Applying the Why question to every element and activity in the Scrum project is yet 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.

To wrap it all up, it’s worth saying that the Scrum Guide 2020 strongly implies that Scrum is still (and probably always will be) based on continuous improvement of all processes: Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials. We can expect that in the future, Scrum Guide will continue to change in order to be even more flexible and focused on tying the product to its business value even more completely. We can also expect the rules and Scrum values to become more and more simplified and generic at the same time. The definition of Scrum is evolving and the Scrum Guide is a good indication where it is going ot go next.