Showing the benefit of Product Goals and Sprint Goals?

Question

I have 2 questions. If we are using Scrum, is it really Scrum if a Product Goal and a Sprint Goal does not exist?

My current situation is that I inherited a project with no project charter or product canvas. Neither exists.

I brought up that I want a Product Goal and a Sprint Goal for the project. I figure it will help me know if the project is successful or not. I have also read the benefits of having them.

However, our Certified Scrum Professional Scrum Masters are telling me that the Scrum Guide is just a guide and the Product Goal and Sprint Goal are not needed. They ran into situations where people created goals that were a summary of User Stories so they stopped using Sprint Goals. They seem to have convinced management that the Scrum Guide is just a guide as well. I am not entirely sold but maybe there is some other context I am not getting.

If I don’t have a Product Goal or a Sprint Goal, what can I put into place to ensure team transparency, collaboration? What can I put into place so that I know the project will be successful?

Answer 1

What is taking the place of Product Goals and Sprint Goals?

There's two ways to approach this. One is to say "without product goals or sprint goals, we're not doing SCRUM." And that works. But the "its just a guideline" argument comes up. So we really should dig deeper. The other way to approach it is to ask "why does SCRUM have product goals and sprint goals?" and then ask why the current project does not have them. It may be because they don't need them due to a business logic reason, or it may be that they are handled with a different named tool.

The big value of the sprint goal that I see is that it defines what "success" means for the sprint (itself a time box). Without it, you either need to define "success" or you need to admit that you cannot measure success at the sprint level. I have seen many environments where we don't really measure success at the sprint level. In government contracting, for instance, one is often told exactly what system to use to measure success (such as EVMS) which does not necessarily map to sprints; they map better to features. In other cases, the "success" metric is simply that you did all of the stories you planned at the start.

From your words, it sounds like the latter case is what is going on. People started writing goals to match the stories, so leadership said "fine, your goals are the stories." This is where I would start approaching changing the culture (if I felt obliged to change it). If your goals are your stories, then you are not agile within a sprint. You are only agile from sprint to sprint. The presence of a sprint goal permits changing stories within the sprint, so long as you can prove that the change supports the sprint goal. Your developers will lack this ability if they don't have a goal.

As for product goals, they may be handled informally or formally. The goal may be shifting. Often the goals are not penned down in words because they are in someone's head. This is obviously bad for the SCRUM goal of being able to show that you spent your effort towards the goal. But it's also a reality. Find that person, and pick their brain. You might be able to get feature goals that act as a proxy for the product goals.

Or the product goal may be more formal. You may have a set of requirements written down in requirements-speak, and the product goal is an unstated "meet all of the requirements." In this case, it may be easy to get a confirmation that the product goal is what you say it is.

Answer 2

This is a multi-faceted question, so I'll try to provide something helpful step-by-step.

First, the Scrum Guide is just a guide, but it is the definitive guide on Scrum. Furthermore, it has been built and refined on decades of experience in companies effectively delivering products iteratively and incrementally. It is not the only proven approach by any means, but it is one. Therefore, while you don't have to follow the Scrum Guide (read: you don't have to practice Scrum), it would be absurd to dismiss the ideas out of hand as if they are simply some person's blog post.

Next, I've never heard of any type of project management approach that doesn't use some sort of Product Goals. Even before it was officially part of the Scrum Guide this past revision, most successful Scrum teams borrowed Product Goal concepts from other places to fill that gap. This solves the problem of aligning all work in the project to its success criteria. If you aren't using a product goal to address this need, it begs the question: how are you solving it? Again, Scrum isn't the only way, but that isn't an excuse to just ignore that aspect of product or project management.

Sprint goals create short-term focus and are vital for moving from an output focus to an outcome focus in teams and that is critical if you are looking to achieve iterative and incremental product development. And honestly, if you aren't, I'm not sure why you're using Scrum at all. Again, not the only solution, but a solid one and if that's not the one you're using, what is it replaced with?

Lastly, I want to address the attitude of the CSPs. If they have this certification, they need to have had some continuing learning and proven experience. Around that point, people are usually encouraged to "tune" their Scrum to meet their needs. I say this because they may have found more effective ways to solve these challenges. However, they may also be falling into a common trap for experts. An expert may be able to operate with more flexibility, but that doesn't mean that this comfort extends to everyone else in the organization. This can leave others with less experience or expertise feeling confused and that is not fair to them. If they are trying to solve the same problems differently, it is reasonable for you to ask for an explanation of how that is supposed to work. It seems like a massive jump to say you can't practice Scrum by having Sprint and Product goals, and there is definitely some explanation owed there.

Answer 3

There is a lot to unwrap here, but it seems that you are in a company that is doing Scrum just by name:

• you don't have Sprint Goals (the 2017 version of the Scrum Guide mentions a sprint goal 27 times, the 2020 version 19 times);
• you don't have a product goal (the 2017 version doesn't use the words "product goal" but the 2020 version mentions it 15 times);
• CSP ScrumMasters tell you the goals are not needed;
• they stopped using Sprint Goals.
• the Scrum Guide is just a guide (true, but more on this below).
• to ensure team transparency, collaboration. Should I gather these aren't already happening?
• so that I know the project will be successful? Isn't there (or was) a product owner responsible for pointing the finger at the target and making sure the team is moving towards it?

Many companies say they are doing Scrum. They have Scrum Masters, they have Sprints, they have daily stand-ups, etc., but in fact just do some form of Waterfall where they have defined the product and now are going through the motions and just churn out tasks each sprint. Focus isn't on value but usually on schedule. The thing was defined so now it's just grunt work with nobody paying attention. So it's not really Scrum, it's a hybrid with some things taken from traditional project management and some from Agile (heavier on practices form the former).

Some companies end up like this after trying to adopt Scrum and failing to do so because of (usually) non-involvement and lack of support from managers and executives (i.e. trying to use Scrum in the development teams only, while everything else remains or is desired to stay the same). Some other companies end up in this situation because they don't understand what Scrum is all about and bring in the wrong kind of Scrum Masters to help them implement it.

Speaking of Scrum Masters, I want to make an aside about the fact that being certified doesn't mean anything. From how you phrased the sentence when mentioning certified scrum professionals, it seems to me that you somehow think that they should know what they are talking about. A certification only means that you studied some material and passes a multi-choice test. That's it. It doesn't guarantee that you then know how to apply the information and help and support a team. Besides, Scrum is a framework which means it doesn't cover all the things specific to each team, product, company, domain, technology, organizational culture, etc., things that can't be learned by pursuing a Scrum certification. A piece of paper doesn't help you navigate all these things.

These might get reflected in the answer you got that the Scrum Guide is just a guide. Yes it is, but it's a guide that outlines a framework (whose latest version mentions both of the things that your SMs say are not needed). So does this mean they haven't kept themselves up to date with what's going on? Does it mean the piece of paper was all they were after and are not really interested in the SM role (not pointing this out to the team is a failure of the Scrum Master)? Does it mean that they are looking at the guide like a list of items to check from a list and then stop there, without adding the needed things to complete the framework?

You need sprint goals and you need product goals. Both of these things are answering the question of "why are we doing this?". If you don't have sprint goals then the goals become to finish the tasks in the sprint. Sure,everyone is busy, everyone has something to do, you can even demo them at the end of the sprint, but why are those things needed? How are they valuable? How do they get you one step closer to what you are trying to achieve with the product goals?

If you don’t know where you’re going, any road will take you there – Lewis Carroll

Finally, if you want to ensure transparency, collaboration and success of the project, then this won't be done by using sprint and product goals but by the people themselves and their openness to enact the Scrum values. So try to get the big picture first (you are now focusing on two items who are most likely a result of some other cause), present your solutions with arguments, get everyone involved in the discussion, and pay close attention to how they respond and where you get assistance and where you get push back.

Answer 4

The Scrum Guide says this:

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.

This makes it clear that if you do not have Sprint Goals and Product Goals, what you are using is not Scrum.

The Sprint Goal has been in Scrum since the very first published Scrum Guides. Product Goals are a relatively new addition, added in the November 2020 revision, but earlier revisions do contain information about product vision. Since the 2020 revision is still relatively new, I can understand a team not having implemented a Product Goal as its described in the Scrum Guide, but it seems reasonable to expect something similar to ensure that the Scrum Team and the stakeholders are aligned on vision and scope for the product.

From my perspective, the question should not be about doing Scrum or not. There are plenty of good development practices that aren't Scrum out there. As useful as I've found them, having a product vision (or a Product Goal as it's described in the Scrum Guide) and iteration goals (or Sprint Goals exactly as described in the Scrum Guide) may not be required for teams to be successful. I would suggest that a team stop saying that they "use Scrum" or "do Scrum" if they are not using all aspects of a recent iteration of the Scrum Guide and working toward aligning with the most recent published iteration.

If you believe that having something like a Product Goal and a Sprint Goal would be helpful to you, this is something that can be brought up at a Sprint Retrospective. This should be a place where you can explain why you think that it is valuable and worth the effort to craft. Depending on your role, you could start to craft these on your own, with minimal support from the team, to demonstrate usefulness. If you are the Product Owner, I would start with crafting a well-defined product vision or a Product Goal to enable you to do your job more effectively. If you show the value of this to the team, it could be easier to convince them to buy into experimenting with Sprint Goals.

Answer 5

I'd suggest this: look at your project, at your company, in your situation, and think carefully: "What is it that I need to know, and for the team to know, in order for this project to be successful? And, to know when it's falling off course?" Whether you (or they) call it "scrum" or not is really not that important. The important thing is that effective planning is being done – usually, at several levels at once – and that project progress and impediments are being accurately captured and communicated.

"Scrum is a guide." Yes, it is. But it's a very good one. Consider carefully why it says the things it does – for what purpose. Your project planning process, whatever "hybrid" it might turn out to be, needs to cover those same purposes.

But: "Scrum is not a religion," and ... "religion will not really help you here, anyway." At the very end of the day, you all have a job to do. All that methodologies can ever offer you is "guidance."

Answer 6

Thank you guys. These responses are definitely helping me construct a conversation with the Agile Coach (a CSP SM). In looking at the recent condensed file, he has on Scrum, the vocabulary is definitely from the 2017 Scrum Guide.

I think the crux of the problem here is I completed certification classes that were based off of of the Scrum Guide 2020. Our CSP SMs, guiding the organizational Agile transition, are basing their conversations off of the 2017 Scrum Guide.

This is going to be very confusing for any newly minted CSM or CSPO if we get any of those later on down the line.

Hopefully, the conversation opens something up and we start to see the training materials updated.