The Three Key Changes to the Scrum Guide That Organizations Need to Pay Attention to

Published: April 23, 2021, noon

This week on the Agile Coaches\u2019 Corner Dan and Sam are switching things up with a new episode format. In this episode, they\u2019re looking back on Sam\u2019s three-part Trainer Talk series on the key changes that were made in the new Scrum Guide that was released in November 2020.

\xa0

This episode compiles all three of Sam\u2019s Trainer Talks that focus on the three key changes that were made to the Scrum Guide around the product goal, the sprint goal, and self-organizing teams. Sam shares his thoughts on why these changes are important to recognize; what these changes mean for organizations, Scrum Teams, and Product Owners; and the specific benefits that come with these changes.

\xa0

Tune in to learn all about the three key changes that organizations using Scrum need to pay close attention to!

\xa0

Key Takeaways

How has the Product Goal Changed with the New Scrum Guide? Why is it important and what are the benefits?

What the Scrum Guide has to say about the Product Goal: \u201cThe Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define \u2018what\u2019 will fulfill the Product Goal\u201d

The Scrum Guide is now making the Product Goal an explicit part of Scrum (which is crucial in creating a unified vision for the team to work toward)

This change highlights the difference between a Product Goal and a Product Vision which is important because a product vision is lacking the characteristics of SMART goals (\u201cspecific, measurable, achievable, relevant, and time-bound\u201d goals)

With the Product Goal in the Product Backlog, the rest of the Product Backlog emerges to define WHAT will fulfill the Product Goal (this has specific benefits such as creating transparency, understanding what the value is that is expected to be created so that the team can validate if their efforts are creating the desired outcome, and in helping the team understand what should be in the Product Backlog vs. what should be out of it)

With a Product Goal being in the Product Backlog and the rest of the Product Backlog emerging around that, it is possible to validate PBIs against the Product Goal

The Scrum Guide also says that \u201cThe Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next\u201d (which is hugely beneficial as it will help teams focus)

With a Product Goal and the expectation that the Product Backlog, by and large, contains items that emerge as a result of that Product Goal, it is possible to make much more meaningful Sprint Goals

The Product Goal helps the Product Owner move beyond being a mere order taker and, instead, create a stance where they are initiating requirements

How has the Sprint Goal Changed with the New Scrum Guide? Why is it important and what are the benefits?

The new Scrum Guide underscores the commitment and purpose of a Sprint Goal

Jeff and Ken introduce a new topic for Sprint Planning in this update, which is: \u201cWhy is this Sprint valuable?\u201d (In other words, \u201cWhat do we hope to get out of it?\u201d) \u2014 Asking this question helps craft the Sprint Goal

Establishing a Sprint Goal allows the team to create a well-rounded SMART (\u201cspecific, measurable, achievable, relevant, and time-bound\u201d) goal

If you don\u2019t have a Sprint Goal, the Sprint Backlog becomes just a list of Product Backlog Items to fill up a team\u2019s capacity with no coherence to it

With a Sprint Goal, the team is able to create a coherent Sprint backlog that will help them meet their goals and objectives

Though there might be things in your Sprint Backlog that are not strongly correlated to the Sprint Goal, doing what is necessary to achieve the Sprint Goal needs to be the priority (If you find that some of these other items keep getting pushed aside, maybe they should be the focus of a Sprint Goal themselves)

Once a Sprint Goal is established and it has helped the team select a coherent group of Product Backlog Items for their Sprint Backlog, the Sprint Goal then helps address the topic of: \u201cHow are we going to do it?\u201d

Good Sprint planning includes creating a plan for working together and breaking things down into the tasks that the team needs to achieve

Without a Sprint Plan, there is a lack of transparency and the Scrum Team cannot see at their Daily Scrums whether or not they are making good progress towards the Sprint Goal

The Sprint Goal creates transparency and the ability for a Scrum Team to deliver reliably and predictably each and every Sprint (additionally, it helps establish a sustainable pace, which creates better morale and a more fulfilling work environment)

How has Self-Organizing Changed to Self-Managing in the New Scrum Guide? Why is it important and what are the benefits?

Even though the change may seem merely semantic, it has a massive impact on how organizations will see Scrum in a new light and will be a shock to those organizations that have not allowed their teams to be self-organizing or self-managing at all

When organizations use Scrum but do not allow their teams to be self-managing this leads to a lack of engagement and a lack of ownership; it destroys morale and causes turnover

In Daniel H. Pink\u2019s book, Drive, he discovered the three factors that truly motivate knowledge workers are autonomy, mastery, and purpose (and self-managing teams leverage all three of these things [and Scrum done well has all three built-in!])

Scrum gives team autonomy by allowing them to decide what to work on and in setting their own Sprint Goal

\u201cScrum encourages mastery. The Scrum team is accountable as a whole for delivery, so there\u2019s no idea that \u2018This is my area and I don\u2019t have to do anything else.\u2019 We all expand our knowledge together and work together.\u201d \u2014 Sam Falco

Self-managing teams create less overhead for managers as they don\u2019t have to spend time directing people and telling them what to do

\u201cSelf-managing is serendipity in development\u201d (when you hand someone a problem, get out of their way, and they will solve it in ways that you never could have imagined [and maybe even better than if you had solved it yourself!])

In complex product development, something new is always going to come up and there is an enormous amount of uncertainty \u2014 Scrum allows self-managing teams to adapt to this uncertainty as it arises and every Sprint offers an opportunity to change direction

You can work towards self-managing teams by empowering your Product Owners to make decisions and shepherd their products; feeding your teams with objectives, not tasks; setting the boundaries within which your teams can make their own decisions and steer their own course; encouraging the Scrum team as a whole to be accountable toward each other and toward achieving positive outcomes

\xa0

Mentioned in this Episode:

The Scrum Guide

Agile Coaches\u2019 Corner: Trainer Talk: \u201cHow Has the Product Goal Changed with the New Scrum Guide?\u201d

Agile Coaches\u2019 Corner: Trainer Talk: \u201cHow Has the Sprint Goal Changed with the New Scrum Guide?\u201d

Agile Coaches\u2019 Corner: Trainer Talk: \u201cHow Has Self-Organizing Changed to Self-Managing in the New Scrum Guide?\u201d

Agile Coaches\u2019 Corner Ep. 106: \u201cWhat\u2019s New with Scrum?\u201d

Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink

\xa0

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!