b'

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\\u201d?

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\\u2019re talking about the commitment associated with the Sprint Backlog: The Sprint Goal.

The Sprint Goal isn\\u2019t new to Scrum. It has been part of the Scrum Guide for at least as long as I\\u2019ve been practicing Scrum. It\\u2019s 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\\u2019re 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\\u2019ve made sure that everyone is fully utilized. That\\u2019s 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: \\u201cWhy is this Sprint valuable\\u201d? In other words, what do we hope to get out of it? What\\u2019s our objective here? What are we trying to achieve? If we want to be blunt, we\\u2019re asking: What value are we going to provide in return for the stakeholder funding we\\u2019re 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 \\u2013 an acronym for specific, measurable, achievable, realistic, and time-bound. I said that a Product Goal fulfills the first two of those \\u2014 and measurable \\u2014 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\\u2019ll 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\\u2019s also time bound by the length of Sprint itself.

When you Don\\u2019t Have a Sprint Goal

If you don\\u2019t 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\\u2019s no coherence to it. And often that leads to other bad patterns like everyone having their own PBIs that they\\u2019re working on and the team doesn\\u2019t collaborate. It\\u2019s everybody working in their own individual silos. I\\u2019ll hear people say things like, \\u201cWe need to stay in our lane\\u201d. And then of course the Daily Scrum becomes a dry recitation of what I did yesterday. It becomes a status report and it\\u2019s 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\\u2019s easy to select items from the top and create a coherent Sprint Backlog, but there\\u2019s some finesse and negotiation in there, too. If the Product Owner comes to the team and says, \\u201cListen, here\\u2019s what I\\u2019m thinking for this Sprint. We need to start generating revenue for our web application. We need to build a way to accept payments\\u201d. Just because something is at the top of the list, doesn\\u2019t mean we have to select it if it won\\u2019t help us achieve the Sprint Goal.

And there\\u2019s also some negotiation between the Product Owner and the Developers. The Developers might say, \\u201cHere\\u2019s 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\\u2019t do all of that. And we can further refine that Sprint Goal to make it really clear what it is we\\u2019re trying to accomplish. For example, we need to accept at least three methods of payment.

Sometimes, teams ask, \\u201cWhat about other stuff we have to do that isn\\u2019t directly tied to the product development\\u201d? We\\u2019re talking about things like technical debt, infrastructure that needs to be taken care of that maybe doesn\\u2019t contribute directly to the Sprint Goal but that needs to get done.

And that\\u2019s fine. There might be things in your Sprint Backlog that aren\\u2019t 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\\u2019ve selected the individual items that they\\u2019re each going to work on, they go their separate ways. If everyone has their work to do and they don\\u2019t really coordinate or collaborate with each other, there\\u2019s 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\\u2019t working in silos will often skip the third part of Sprint Planning so that \\u2013 and I hear this phrase a lot \\u2013 \\u201cSo that we can start working.\\u201d 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\\u2019t 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\\u2019t see every day at Daily Scrum whether it is making good progress toward the Sprint Goal. They don\\u2019t know if they need to adjust their scope. They don\\u2019t 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\\u2019t tell if the team\\u2019s being effective. And that probably means they\\u2019ll pester the team more, which has implications for self-management \\u2014 which I\\u2019ll 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\\u2019m going to talk about how they do that in the next episode when I talk about the term self-managing. So, I hope you\\u2019ll 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\\xa0upcoming web meetings
• See available\\xa0training courses

\\xa0