b'

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\\u2019s 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\\u2019 Corner podcast, titled \\u201cWhat\\u2019s new with Scrum?\\u201d That was a few days after the Scrum Guide came out. Now that we\\u2019ve had time to absorb the changes, I wanted to revisit them. In this three-part series, I\\u2019ll examine three changes that I think organizations using Scrum need to pay close attention to. And the one I\\u2019m 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\\u2019ve seen levied at Scrum is that it doesn\\u2019t 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\\u2019re building and why they\\u2019re building it.

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

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\\u2019ve 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\\u2019s 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\\u2019s not measurable \\u2014 or at least it\\u2019s not easily measurable. We don\\u2019t know if it\\u2019s achievable until we try. It is relevant to our business, but there\\u2019s no time statement in there. So it\\u2019s not a SMART goal. It\\u2019s 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\\u2019s at the very least specific and measurable. We might not know if it\\u2019s achievable or realistic until we try. It might be time boxed, but it isn\\u2019t 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\\u2019s 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, \\u201cCreate a rainforest hike package that will appeal to young couples\\u201d. That is specific and measurable: We know what it is we\\u2019re trying to achieve; we know who we\\u2019re targeting, and we will know when we\\u2019ve 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\\u2019re building the product, and we know whether it makes sense to keep building this product. Is the \\u201cwhy\\u201d 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\\u2019re 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\\u2019s 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\\u2019ve seen a lot of Product Backlogs that are huge lists of unrelated requests. We just shove it in the junk-drawer and don\\u2019t 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\\u2019t 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 \\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.

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\\u2019s not a specific product at all that they have in mind, they\\u2019re 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\\u2019ll talk about the Sprint Goal and Sprint Planning in the next episode.

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

People take vacations, for one thing. But beyond that, a Product Owner isn\\u2019t going to be with the Developers 100% of the time. Not if they\\u2019re 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\\u2019s 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\\u2019re told, \\u201cYou just write down what stakeholders tell you. Your contribution is ordering the list, but we\\u2019re going to get all the stuff stakeholders ask for\\u201d. Those Product Owners are just proxies or scribes.

What\\u2019s 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\\u2019s good for the business and what\\u2019s good for the product. Here\\u2019s 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\\u2019t, and here\\u2019s 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\\u2019ll 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\\u2019d 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\\xa0upcoming web meetings
• See available\\xa0training courses

\\xa0