Preview Mode Links will not work in preview mode

Agile Coaches' Corner shares practical concepts in an approachable way. It is for agile practitioners and business leaders seeking expert advice on improving the way they work to achieve their desired outcomes. If you have a topic you'd like discussed, email it to podcast@agilethought.com, or tweet it with #agilethoughtpodcast.

Apr 23, 2021

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

 

This episode compiles all three of Sam’s 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.

 

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

 

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: “The 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 ‘what’ will fulfill the Product Goal”

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 (“specific, measurable, achievable, relevant, and time-bound” 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 “The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next” (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: “Why is this Sprint valuable?” (In other words, “What do we hope to get out of it?”) Asking this question helps craft the Sprint Goal

Establishing a Sprint Goal allows the team to create a well-rounded SMART (“specific, measurable, achievable, relevant, and time-bound”) goal

If you don’t have a Sprint Goal, the Sprint Backlog becomes just a list of Product Backlog Items to fill up a team’s 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: “How are we going to do it?”

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’s 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

“Scrum encourages mastery. The Scrum team is accountable as a whole for delivery, so there’s no idea that ‘This is my area and I don’t have to do anything else.’ We all expand our knowledge together and work together.” — Sam Falco

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

“Self-managing is serendipity in development” (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 — 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

 

Mentioned in this Episode:

The Scrum Guide

Agile Coaches’ Corner: Trainer Talk: “How Has the Product Goal Changed with the New Scrum Guide?”

Agile Coaches’ Corner: Trainer Talk: “How Has the Sprint Goal Changed with the New Scrum Guide?”

Agile Coaches’ Corner: Trainer Talk: “How Has Self-Organizing Changed to Self-Managing in the New Scrum Guide?”

Agile Coaches’ Corner Ep. 106: “What’s New with Scrum?”

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

 

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!