January 13, 2021


Watch the Video


Listen to the Audio


Summary

If you would like to increase your Sprint success rate, and your product development focus, take a closer look at Sprint Goals.

This episode covers the power of skilful Sprint Goal definition and offers guidance in crafting strong Sprint Goals.

Firstly, the product backlog items the team chooses for the Sprint are not Sprint Goals. The Sprint Goal is the overarching goal for the Sprint.

As of late 2020, the Scrum Guide includes the need for setting a Product Goal. If you are using a Product Roadmap (if not, please do), then the Product Goal from Scrum is probably best compared to a milestone on your Product Roadmap.

In the context of the Product Goal, a number of Sprint Goals are required in order to realise the Product Goal.

When defining a Sprint Goal, consider how you determine whether it has been achieved. Can you test this at the point of the Sprint Review? If not, then you can’t determine whether you have met the Sprint Goal.

This episode covers this and additional points in terms of measuring your accomplishment of the Sprint Goal.


Quote Cards


Listen on Spotify


Full Transcript

- "Hello, hello and welcome. sprint goals, do you have them? How are they working for you? Perhaps they need some tweaking? How do you know whether they're even good ones? This and more coming up in this very episode of Team Genius Live. 

Hello, hello. My name is Georg. Happy Friday to you. I hope you've had a good week together with your team. I have come back from a few days of in-person work which was very great together with a friend and partner here in Portugal, and I've just checked some of messages and saw that and YouTube statistics as well as reader counts on my blog articles and it turns out that's to this date, the content that I have produced on the sprint goal is still in demand. 

And I've also checked elsewhere and it looks like, Hmm, there must be something to this sprint goal thing. So I certainly have a few stories accumulated over the last 10 years. So I got to learn and practice and tweak the sprint goal approaches. So let's start with some of the background. So of course the sprint goal comes from the Scrum framework where we are looking for a specific purpose for any given sprint or iteration that you're working on together with your team.

Now, there are a few pitfalls that you might want to watch out for that we're gonna cover as well. And for some situations it might be useful to even clarify what the actual real purpose is and how the sprint goal fits into the overarching construct of everything else that is going on in the Scrum framework and some ancillary practices that might be out there. 

Okay, so following Simon Synek's advice "Always start with why" let's delve into the purpose. The sprint goal is actually exactly that. It gives the sprint a purpose, a purpose that is big enough to be elevated above all the items that the team is pulling into the sprint backlog from the product backlog. And it is also low enough to fit multiple spring goals towards a milestone on your product roadmap. 

Now, if product road mapping is something that you are still working towards, or whether it's something that you already have it is definitely something that I would recommend doing because in itself it is a wonderful middle layer that helps you to engage very well with your stakeholders and also help to path away that helps you to realize the product vision but we can cover that in a future session. 

Now let's come back to the sprint goal. So it gives purpose and that also leads us to the most common pitfalls that even I have to admit that I have fallen into for a period of time. The sprint goal is not plural, it is single. There is only one sprint goal for every sprint. I have made a mistake that for some reason or another, I forgot about what the spring goal is actually supposed to be and we ended into the pitfall that every item in the sprint backlog ended up as a sprint goal, which is really, really bad and it was certainly not easy for us. We kind of made it work and it was okay, but it wasn't good and it exposed us because if every item in your sprint backlog becomes a sprint goal and you as a team want to commit on each of those items then you're bound to fail at least part of what you were aiming for which makes it difficult to have a sense of achievement at the end of the sprint.

Not everything works out perfectly. So a couple of things can happen. One is you either play it too safe and only take fewer items into the sprint, or you get over ambitious and then you fail your sprint goals. So best to actually do it properly, remind ourselves that there is only one sprint goal out there and ensure that you have real clarity on what that actually is. So the sprint goal, how does it come about? It is set by the product owner necessarily of course, in collaboration with the team. So it's not a surprise that it comes. It will be brought about in product backlog refinement. 

You might recall if you've watched the live session on product backlog refinement that I've talked about the sprint goal. I've referenced the sprint goal there as well. It is set by the product owner ultimately and it is what motivates the choices of the development team when it comes to pulling items from the product backlog into the sprint backlog. It is one goal that is achievable in the sprint and it is a goal that helps the team to make some significant step forward towards realizing the product and hopefully you have a product roadmap whichever is the next milestone on the product backlog roadmap. It is at a level that should be easy enough to follow for busy stakeholders also so that it can have a meaningful conversation around it and it should be something of value to the end user. 

So for example if you were to think, well, implement technology XYZ, who would understand what the value is if that was our sprint goal? If that works in your context, great but most of the time it's not really so relevant. So if you're talking about a specific, kind of exposing my weakness here because I chose something that's very technical and that is not my strongest suit but implementing some technology that's related to how your data storage works. That might mean something to the technically inclined on your team, but it wouldn't mean much to your end users in most contexts and it might not mean much to many of your stakeholders, but if you actually looked at what is the value that this particular technology would bring and elevate it there, then it would be more around the customer experience, the user experience I'm presuming. 

So reduce the loading experience of search results by whatever seconds or milliseconds or percent or whatever it might be. So if that is the goal, that gives also a clear target for the development team to achieve. So it is specific, it is something that can be achieved in the sprint, one would hope and it also gives something that is measurable. So necessarily with baseline and workout what's the experience like right now and then set an achievable goal that it can then translate as the spring goal, excuse me. So that might be something that is useful and stakeholders can understand that and hopefully users can also understand that better in those terms, compared to the actual technological tweaks and tricks that the team is done choosing in order to pursue that. Right? 

So, as I mentioned, a sprint goal is not coming as a surprise in sprint planning. The sprinkle will have been shared beforehand potentially as early as roadmap updates together with the team where we're saying, "Okay, so, you know, if this is the product roadmap milestone that we're pursuing, then largely we're speaking of these values of chunks on the way to get there." And then in product backlog refinement, you would then identify the actual items that would support these particular goals. 

The other aspects that are worth considering when it comes to sprint goals is that you might have some ideas for things that you cannot actually validate at the end of the sprint. So that's a little bit tricky. If you wanted to do that but you actually need customer feedback for that, then you would necessarily need to consider that before you declare that as the sprint goal as a team. So for example, you could do that if you were able to actually achieve that already in the earlier part of the sprint, launch it to a smaller segment of your end users, hiding it through feature toggles and user segmentation from other parts of the user base and then get a feedback through data analysis by the end of the sprint. 

So if you're choosing something that can actually only be tested through feedback or usage from your actual target audience as your spring goal, make sure that you have the ability to actually validate that because otherwise you are at the end of the sprint, and you're looking to get the spring goal in the sprint review with your team and you don't have the data yet which means you cannot validate whether you've met the sprint goal, so strictly speaking for all intents and purposes, you have been unable to meet the sprint goal. What you can do is to split the sprint goal into leading indicators and lagging indicators. Leading indicators would be something that you can actually validate at the time of the sprint review when the sprint ends and you can supplement that with why you wanted to do this particular tweak as a lagging indicator, where you need to get usage statistics or customer feedback that you could do afterwards. 

So that all depends on your ability to release the functionality or the work into the hands of the users and get feedback. Ideally, you would obviously be able to release whenever you want to depending on your setup, that may not be possible. So you need to bear in mind when you can actually validate your achievement of the sprint goal as you do that. Now, I'm just checking my notes here. What else we wanted to get through when it comes to the sprint goal? Right, one other important aspects that I like to reference is the motivational aspect. Now, imagine if you didn't set sprint goals and all you did was to basically fill the sprint backlog based around the capacity of the team for any given sprint. And instead of sprint goals, all you do is you number your sprints. 

And imagine that in your team, you've been working together for a year, year and a half, and you're looking at well if your sprints are two weeks length, then you might be at about 100, 150 or 200 sprints. And you have your sprint planning sessions say, "Hey, welcome to sprint planning for sprint number 137. Our capacity is gonna be 11 per backlog items or however many story points worth of capacity based on people's absences and our historical performance as a team." What would you like to pull into the sprint backlog now? Yeah, obviously what's at the top of the product backlog. Okay, great. So let's do it and get on with it. That's very mechanical and procedural and technically speaking, you would, do it correctly with the absence though, of a sprint goal. 

The sprint goal is an integral part of the Scrum framework. Without the sprint goal, the team doesn't have any sense of purpose of why they're doing the work in the given sprint. Yes, you could remind them of the overarching product vision and remind them of their service to the target audience through whichever technique you're practicing user personas, user archetypes or whatever you're doing in order to maintain that empathic connection with the target audience. But when it comes to the sprint by sprint experience, there is very little sense of purpose or perhaps also urgency because there is no grouping and no meaning to the bundle of work, the bundle of value that they are creating. 

So it's really helpful from a motivational point of view also to not skip the identification formulation of a compelling sprint goal because it will help to reinvigorate the team with a sense of purpose, every single sprint and provide more meaning to the work that they are doing. And having a sense of purpose is very important, of course especially for the world of knowledge work that we're doing. And without that, it is quite difficult to carry it through the sprint and it can become quite mechanic. So this is also another argument for doing that. And I wanted to reiterate something around the stakeholder landscape. 

When you interact with your stakeholders, either in person or remotely or even when you do it through information radiators in team spaces or a team, virtual or physical, it is also quite easy for you to broadcast or maintain transparency around the sprint goal versus the items that are currently in progress where obviously it takes more time for people to read through what is currently in the sprint backlog and what's being worked on by the team and it's much easier for them to get a sense of what the team is working on if there is a sprint goal. So what is the team up to this week? They're doing this item, that item, that item. People may not have the time or the cognitive attention capacity based on everything else that's going on for them in their work to absorb item by item, by item information. 

So again, grouping them into a meaningful goal and or associating them with a meaningful goal to sprint goal is a lot better for stakeholder engagement as well. So that summarizes some of the key aspects that I wish for you to bear in mind when you are crafting your sprint goals. Make sure they're meaningful, make sure they're compelling, make sure that you can achieve them and you have a way to measure and validate them by the end of the sprint so that you can celebrate something at the sprint review. And that is the last thing that I wish to include. 

When you come to the sprint review you check whether you have met the sprint goal or not. If you have met the sprint goal but you have not delivered every single item, that's okay. You still have met the sprint goal. You then put the items that were not completed back into the product backlog and go through them in refinement and see whether it needs to go into the next sprint to support the next sprint goal or whatever else you need to do. So can you have a successful sprint if you don't deliver all the items? Yes, you can, as long as you have met the sprint goal. So you need to be clear when you start the sprint and sprint planning, which items are required to realize the sprint goal and which items are an added bonus, if you will. 

So this is up for the product owner to agree with the product development team. And it is useful to ensure that you bear in mind that not everything may go smoothly and you give yourself a good but challenging sprint goal that helps you to be achievable by the end of the sprint, okay? So that gives you something to celebrate by the end of the sprint and that will also help with continued motivation as you go over through your sprint cadence. 

All right, now these were all the ideas and the experiences that I have got to accumulate so far. If you have anything else to share, that would be good here. Please feel free to add them in the comments. I would also like to let you know that I am considering doing some interviews in these live sessions. So if you have some curious, inspiring, useful, valuable stories to tell about the teamwork that you've experienced and other stories worth sharing then feel free to get in touch either through a comment here or connect with me on LinkedIn and we can have a chat to see whether we might want to have a conversation in one of these live sessions in the future. 

So I hope you'll consider that and let me know. Any other requests for topics would also be much appreciated. And with that, I would like to thank you very much for tuning in, for watching this video. If you found something of value in here, please consider giving it a like and if you haven't yet subscribed, consider doing so. You'll get some new videos in your stream and if you'd like to get updates on when new videos are coming make sure you hit that bell button. So with that, I would like to thank you very much for watching. This has been Georg for Team Genius Live. 

I wish you all the best for the practice with your team. 

Thank you very much. And goodbye."

==end of transcript==

Thanks for reading this article!

Who in your networks might find it useful? 

Please kindly share it with them ...

About the author 

Georg Fasching

A leadership team development specialist, International Coach Federation - Professional Certified Coach, with global product management experience since 2000, employing Agile & Lean since 2010, Georg Fasching guides leadership teams to delighting their clients, fulfil their people, and improve their prosperity.

Leave a Reply

Your email address will not be published. Required fields are marked

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hone your Product Craft, Coaching Craft, and Leadership Craft with 

weekly videos & Live Streams.