How Has the Product Goal Changed with the New Scrum Guide?

In this episode, part one of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco answers the question: "How Has the Product Goal Changed with the New Scrum Guide?"

What’s New in the Scrum Guide?

The more I think about the new edition of the Scrum Guide, the more excited I am about the changes. Scrum is still Scrum of course. Nothing changed about how Scrum works or the value it brings.

But by stripping out prescriptive elements, Ken and Jeff have given us a Scrum Guide that makes its purpose and value clearer. Organizations that truly embrace this iteration of Scrum are going to supercharge their product development efforts.

Dan Neumann and I talked about the changes to the Scrum Guide in episode 106 of The Agile Coaches’ Corner podcast, titled “What’s new with Scrum?” That was a few days after the Scrum Guide came out. Now that we’ve had time to absorb the changes, I wanted to revisit them. In this three-part series, I’ll examine three changes that I think organizations using Scrum need to pay close attention to. And the one I’m going to talk about in this episode is the introduction of the Product Goal as the commitment associated with the Product Backlog.

The Product Goal and the Product Backlog

As I mentioned in episode 106, a criticism that I’ve seen levied at Scrum is that it doesn’t provide a unified vision for the team to work toward. Without that vision, the team lurches from short-term goal to short-term goal and Developers struggle to understand what they’re building and why they’re building it.

It’s true that Scrum didn’t tell you to create that goal. Of course, nothing prevented a Product Owner from doing that, either, and the best Product Owners I’ve worked with did just that. With the Scrum Guide making that Product Goal an explicit part of Scrum, it’s going to make a big difference in the way people look at how they’re practicing Scrum. Here’s 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”.

So, the Product Goal is the why and the rest of the Product Backlog is the what.

I like that statement because it describes a future state of the product to plan against. I think this shows us what the difference is between a Product Goal and a Product Vision.

How Does the Product Goal Create a Broader Vision?

You’ve probably heard of SMART goals. SMART being an acronym for specific, measurable, achievable, relevant, and time-bound.

A product vision may lack some of those characteristics.

Let’s imagine we are running a vacation resort and our vision is to become the destination of choice for travelers to our region. That is pretty broad, rather than being specific. It’s not measurable — or at least it’s not easily measurable. We don’t know if it’s achievable until we try. It is relevant to our business, but there’s no time statement in there. So it’s not a SMART goal. It’s inspiring, but by itself, that vision is not enough to give a Scrum Team what they need to know and how to move forward.

A Product Goal is a concrete step toward realizing that broader vision. It’s at the very least specific and measurable. We might not know if it’s achievable or realistic until we try. It might be time boxed, but it isn’t always. Sometimes, instead of setting a release date, the release boundary is the features the product must have. The release date is flexible. Often, of course, we have a time constraint. For our imaginary resort, we might want to make a new product available around the time people start planning their vacations for our tourist season.

So, our imaginary resort’s vision is to be the destination of choice for travelers to their region. What does a Product Goal look like?

It might be something like, “Create a rainforest hike package that will appeal to young couples”. That is specific and measurable: We know what it is we’re trying to achieve; we know who we’re targeting, and we will know when we’ve achieved it.

Looking back again at that definition of Product Goal: The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define WHAT will fulfill the Product Goal. That has some specific benefits.

The Product Goal creates transparency. We know why we’re building the product, and we know whether it makes sense to keep building this product. Is the “why” still a concern? If not, we can end the product development effort. Our imaginary resort can look at whether young couples are responding to our offerings, or whether they even travel to our region at a rate high enough to justify the cost of developing the new product.

The Product Goal helps us understand what value we expect to create so we can validate if our efforts are creating the desired outcome. As our resort creates initial increments of the product, it can monitor how often young couples purchase the rainforest hike package, how much they’re willing to pay, and what they say would make it better.

The Product Goal helps us understand what should be in the Product Backlog and what should be out of it. Our resort’s goal is targeting young couples, so the team can weed out child-friendly options for the product.

How Does the Product Goal Help the Product Owner?

I’ve seen a lot of Product Backlogs that are huge lists of unrelated requests. We just shove it in the junk-drawer and don’t think about whether or not we really need it. With a Product Goal being in the Product Backlog and the rest of the Product Backlog emerging around that, we can always validate our PBIs against the Product Goal. Should this be in here? Would this contribute to the Product Goal? When someone wants to ask the team to do something, it gives Scrum Teams a way to avoid non-value-added work or at least work that doesn’t contribute to the Product Goal.

Because remember, the Product Owner can delegate Product Backlog Management activities to others. With a Product Goal that provides guidance to those delegates as to what they should be doing, activities like Product Backlog refinement become easier.

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”.

I love this statement because it will help teams focus. A lot of teams face the problem of being asked to do too much. They are asked to work on multiple products or work on multiple goals within one product. Sometimes there’s not a specific product at all that they have in mind, they’re just working through that requirements junk drawer.

That damages morale, it damages performance. It damages the ability to deliver value for the organization.

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, we can make much more meaningful Sprint Goals. Remember that initial criticism that I talked about that teams lurch from Sprint to Sprint without any overall vision. This really helps that Sprint become a step toward the Product Goal which is a step towards a product vision. I’ll talk about the Sprint Goal and Sprint Planning in the next episode.

Having a Product Goal means that when the Product Owner isn’t available during a Sprint, Developers can make decisions about Product Backlog Items they’re working on to align what they’re building with the Product Goal. Because sometimes the Product Owner isn’t available.

People take vacations, for one thing. But beyond that, a Product Owner isn’t going to be with the Developers 100% of the time. Not if they’re going to be doing the rest of the job well, which is to be talking to stakeholders, understanding what they need. Talking to customers, understanding what they need. Doing market research. What is the competition doing? That all takes away from the Product Owner’s availability to Developers. With a solid Product Goal, Developers can move forward in the absence of the Product Owner, and then they can coordinate with their Product Owner when the Product Owner becomes available again.

The Product Goal helps the Product Owner move beyond being a mere order taker. Often, new Product Owners are just receivers of requirements. They’re told, “You just write down what stakeholders tell you. Your contribution is ordering the list, but we’re going to get all the stuff stakeholders ask for”. Those Product Owners are just proxies or scribes.

What’s better is when Product Owners can move away from that receiver of requirements stance and instead create a stance where they are initiating requirements. Where they are a true representative of what’s good for the business and what’s good for the product. Here’s how this product will help the business. When someone asks for a new feature, the Product Goal helps a Product Owner take a stand: That aligns with the Product Goal or it doesn’t, and here’s why. This helps Product Owners move toward an entrepreneurial stance which helps in creating good, valuable products.

Getting More out of Using Scrum

So, if you want to get more value out of using Scrum, make sure you have a strong Product Goal. Empower Product Owners and the Scrum Teams of which they are a critical part, to focus on realizing that goal.

Next up, we’ll talk about how the new emphasis on the Sprint Goal as a commitment in the Sprint Backlog changes our approach to Sprint Planning. Meanwhile, I’d love to hear what you think. If you have a question or a comment, please email us at podcast@agilethought.com.

Want to Learn More or Get in Touch?

• Register for our upcoming web meetings
• See available training courses