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

In this episode, part two of a three part series on the new Scrum Guide, Professional Scrum Trainer Sam Falco helps you improve Sprint Planning by answering the question: "How has the Sprint Goal changed with the new Scrum Guide”?

The Sprint Goal and the Sprint Planning

In my last episode I talked about introduction of the Product Goal and how that changes the way we see the Product Backlog. The Product Goal is the commitment associated with the Product Backlog. In this episode, we’re talking about the commitment associated with the Sprint Backlog: The Sprint Goal.

The Sprint Goal isn’t new to Scrum. It has been part of the Scrum Guide for at least as long as I’ve been practicing Scrum. It’s what the teams commit to at Sprint Planning. Scrum Teams are not supposed to commit to a scope of work but a goal which guides us in selecting and adapting the scope.

The new Scrum Guide underscores that commitment and its purpose. I think it will help teams understand why they’re doing Sprint Planning in the first place. That Sprint Planning is not merely an exercise in selecting the top X number of items off the Product Backlog and doing that until we’ve made sure that everyone is fully utilized. That’s not the purpose of Sprint Planning. And that view is one of the reasons that Sprint Planning becomes such a tedious chore for so many teams.

Earlier Scrum Guides talked about the need to craft a Sprint Goal as part of determining what Product Backlog Items we will select. In the new Scrum Guide, Jeff and Ken make it clear how important this is by introducing a new topic for Sprint Planning: “Why is this Sprint valuable”? In other words, what do we hope to get out of it? What’s our objective here? What are we trying to achieve? If we want to be blunt, we’re asking: What value are we going to provide in return for the stakeholder funding we’re spending?

So, we start by asking the question, why is this Sprint valuable? Answering that question helps us craft our Sprint Goal.

The Sprint Goal and SMART Goals

I talked in the previous episode about the idea of SMART Goals – an acronym for specific, measurable, achievable, realistic, and time-bound. I said that a Product Goal fulfills the first two of those — and measurable — but it might not fulfill the other three. But with the Sprint Goal, I think we fulfill all five criteria.

Like the Product Goal, the Sprint Goal is specific and measurable. We’ll know whether we have achieved it. But here we have a much better idea of being able to be realistic and achievable. We want to achieve our Sprint Goal every Sprint, so we do need to select an achievable goal and of course, it’s also time bound by the length of Sprint itself.

When you Don’t Have a Sprint Goal

If you don’t have a Sprint Goal, as I said earlier, the Sprint Backlog becomes just a list of Product Backlog Items to fill up our capacity. There’s no coherence to it. And often that leads to other bad patterns like everyone having their own PBIs that they’re working on and the team doesn’t collaborate. It’s everybody working in their own individual silos. I’ll hear people say things like, “We need to stay in our lane”. And then of course the Daily Scrum becomes a dry recitation of what I did yesterday. It becomes a status report and it’s not a collaboration meeting.

These dysfunctions can stem from not having a strong Sprint Goal. If we have a Sprint Goal, then we can create that coherent Sprint Backlog that will help us meet it.

How to Order your Product and Sprint Backlog

Now ideally the Product Backlog is ordered so it’s easy to select items from the top and create a coherent Sprint Backlog, but there’s some finesse and negotiation in there, too. If the Product Owner comes to the team and says, “Listen, here’s what I’m thinking for this Sprint. We need to start generating revenue for our web application. We need to build a way to accept payments”. Just because something is at the top of the list, doesn’t mean we have to select it if it won’t help us achieve the Sprint Goal.

And there’s also some negotiation between the Product Owner and the Developers. The Developers might say, “Here’s how much we think we can do. We know you want all the credit cards and PayPal and Apple Pay, and so on, but we can’t do all of that. And we can further refine that Sprint Goal to make it really clear what it is we’re trying to accomplish. For example, we need to accept at least three methods of payment.

Sometimes, teams ask, “What about other stuff we have to do that isn’t directly tied to the product development”? We’re talking about things like technical debt, infrastructure that needs to be taken care of that maybe doesn’t contribute directly to the Sprint Goal but that needs to get done.

And that’s fine. There might be things in your Sprint Backlog that aren’t strongly correlated to the Sprint Goal. But 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.

The Third Step of Sprint Planning

Once we have a Sprint Goal and it has helped us select a coherent group of Product Backlog Items for our Sprint Backlog, the Sprint Goal also helps us in the third topic in Sprint Planning. Namely, how are we going to do it? Teams that work in silos, once they’ve selected the individual items that they’re each going to work on, they go their separate ways. If everyone has their work to do and they don’t really coordinate or collaborate with each other, there’s often no point in sitting there, figuring out a plan. Each person is going to go off and do their own thing. When we are truly working toward a common Sprint Goal, when we are working toward a common plan that derives from that Sprint Goal, it behooves us to sit down together and figure out what our plan is.

But even teams that aren’t working in silos will often skip the third part of Sprint Planning so that – and I hear this phrase a lot – “So that we can start working.” Well this is part of the work. Good Sprint planning includes creating a plan for working together. Breaking things down into the tasks we need to achieve. We don’t need to forecast every single thing we might need to do. Just enough to get started, that we can show progress every day and that we can uncover what else we need to do as we go.

Without that plan we have a lack of transparency. The Scrum Team can’t see every day at Daily Scrum whether it is making good progress toward the Sprint Goal. They don’t know if they need to adjust their scope. They don’t know if they need to renegotiate which Product Backlog Items belong in the Sprint or what the scope of each PBI is.

Lack of transparency also means that people outside the team can’t tell if the team’s being effective. And that probably means they’ll pester the team more, which has implications for self-management — which I’ll talk about in the next episode. So, having that plan means good transparency for everyone involved and it gives us a much better chance of achieving a positive outcome.

The Importance of the Sprint Goal

So, a Sprint goal flows from our Product Goal. The Sprint Goal should be a step toward achieving the Product Goal. The Sprint Goal creates transparency, and it creates the ability for a Scrum Team to deliver reliably, predictably, each and every Sprint and to do it without having to overwork themselves. It helps us establish a sustainable pace, which gives us better morale and a more fulfilling work environment.

I’m going to talk about how they do that in the next episode when I talk about the term self-managing. So, I hope you’ll join me here for that episode. Meanwhile, 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