Thanks for your interest in Sprint Goals. In this article I’m excited to share the what, why, and how of creating great Sprint Goals.
The Scrum Guide advises us that:
The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
Although there are several references to the Sprint Goal in the Scrum Guide, the importance and meaning is not necessarily all too clear. Therefore it is understandable that not all teams use them effectively. Please allow me to assist in shining a light on the purpose and benefits of the Sprint Goal.
The Sprint Goal can either be an overarching output, or better yet also an outcome, that gives the work of the team a single purpose.
Ideally your team/your Product Owner would use a product roadmap to map out the … roadmap … of realising the product. Typically multiple Sprints are required in order to realise value-bundles that are represented on the roadmap as ‘milestones’. So you can think of the Sprint Goal of each Sprint as a piece that contributes to realising the roadmap milestone the team is currently working towards.“It’s important to see the sprint goal as a stepping stone for the product to reach the next milestone on the roadmap” Click To Tweet
The key benefit of this is that in order to achieve the Sprint Goal, the team doesn’t necessarily need to deliver all product backlog items that they pulled into the Sprint Backlog during Sprint Planning.
This means that the team could successfully realise the Sprint Goal, although they were unable to deliver certain product backlog items. The Sprint goal provides a great balance between alignment and autonomy for the value creation by the team in a Sprint. This can relieve a good degree of stress, compared to a team either pushing itself, or being pushed to deliver every single product backlog item that they pulled into the Sprint Backlog.
As a side note, when practicing as a Scrum Master/Coach, I made the mistake of missing to correctly introduce Sprint Goals. While each Sprint had a theme, the actual items that the teams were working on became the “Sprint Goals”. Please don’t repeat my mistake. A theme is likely too vague, and there is only one Sprint Goal; it is realised through a significant sub-set of the product backlog items that the team pulls into the Sprint Backlog during Sprint Planning. Now back to the benefits …
Having a common goal to rally around that means something to the team, is also great for morale. Imagine a team that numbers its Sprints and doesn’t use Sprint Goals. After 53 or so Sprints that every Sprint might easily feel like the same and it’s Groundhog Day for the team. Instead each Sprint has a meaningful goal that clearly communicates how the team’s work creates value for its users/customers.
Finally, the Sprint Goal is described in a language that everyone can understand, including stakeholders and of course the users/customers, just like all items in the Product Backlog ought to be. The added benefit to stakeholders is that the Sprint Goal is of a level of granularity that is more meaningful to them compared to the level of each individual Product Backlog Item.
To answer this question we need to first clarify what the difference between those even is, output and outcome.
An output is something that you create and is usually easily countable. For example, a new feature that your team creates is an output.
An outcome is something which is happens based on what you create and is often not easily countable. For example, the impact on customer satisfaction of this new feature that your team created is an outcome.
So you see that an output is also more readily observable, while an outcome could take some time before it becomes observable.
Either could work as an objective, described in your Sprint Goal. Just be appreciative of these considerations. Having an output as your Sprint Goal is more practical to start with.
You could also combine output and outcome in your Sprint Goal. It seems it’s time for some examples.
Features created in the Sprint are created via the list of product backlog items you’re taking into the sprint. The sprint goal is the reason you’re taking these features in this iteration, for example; improving user registration by 5%. It is a stepping stone along the product roadmap and there are different ways this can be achieved.
By keeping this in mind, you can spend time during sprint planning negotiating how you achieve this (the features). This lets the team share insight into more effective ways to achieve a sprint goal without blindly completing tasks that may or may waste valuable business time and attention.
Remember that the team work together iteration after iteration, which can make it difficult to maintain intrinsic motivation. One way to keep this up is to make the sprint goal relevant and meaningful to the team. Think about what benefits the end user–if it resonates with them, it will resonate with the team.
It’s always useful to understand the wider product roadmap. It’s also useful to set a mini purpose for the duration of the sprint to keep all parties on the same page. When the purpose of the current iteration is clear, it inspires the team and stakeholders alike. Some example purposes include the following:
-Hi, Georg here, helping you unlock your team’s genius.
Welcome back to another episode in the series Power of Three, where I’m spending three minutes to share my top three encouragements for any particular subject.
In this video we are going to focus on the sprint goal, or the iteration objective, the iteration goal.
And with that, let us put three minutes on the clock.
Right. So, first and foremost I’d like to clarify that the sprint goal is not the lists of each individual item that you’re agreeing to take into the sprint. Those are the features, those are the individual items, the products that you are dedicating the iteration to.
That is not the sprint goal.
The sprint goal is the Why, it’s the purpose of how come you’ve chosen those particular features for this particular iteration that you are working in a team.
So when it comes to then working out the sprint goal, it is also very very important to bear in mind that the sprint goal is set for the duration of the iteration and it is a stepping stone to get the team closer, for the product to reach the next milestone on the road map. And, as such, sometimes you might work out that you can achieve that goal in different ways, and that’s why the sprint goal has to be somewhat negotiable.
And that is what you dedicate a proportion of the planning meeting, at the beginning of the iteration, to. So the Why of the sprints, the sprint goal, the purpose of the sprint, of the planning iteration, that is of course set by the product manager or the product owner, but How, that has to be negotiable. Because in the planning conversation with the team, you might come up with very simple yet effective ways of achieving a sprint goal, rather than loading up the print with too many things that you don’t end up needing in order to satisfy the sprint goal, right?
So, it is also quite important to ensure that you pick a sprint goal that is very meaningful. So if you imagine, for a team that is working together, iteration after iteration after iteration after iteration, we want to ensure that we have consistent, intrinsic motivation for the team. Intrinsic sense of purpose for every single planning period that the team is working in together.
Therefore you want to pick a goal that is truly meaningful, not only for the product, but really resonates with people.
If it resonates with the user, it is very likely that it resonates with the team. So make sure that the goal is truly meaningful.
And that again comes back to the purpose, right? With the sprint goal you can set a mini purpose for each planning iteration, and when that is very clear that what it is doing for the product is very inspiring as well for the team, and of course the stakeholders.
For example, that purpose can be, we need to test our most strong assumptions, our biggest assumptions at the beginning of the product lifecycle. Or, a little later on, we want to grow our user base and therefore we are gonna do this, and that is the goal for this planning iteration. Or we want to launch a new, bigger feature for the benefit of the user, and that is the goal of this sprint.
So, these were my top three encouragements for your sprint goal.
Thank you very much for your time today.
Please like the video if you found something useful in it, please share it with your colleagues and friends in the community.
Please subscribe to the channel in order to get updated on new videos.
And of course, please share your thoughts on this video, and any ideas for future videos, in the comments.
Thank you very much. Bye bye.
I hope the write-up, the video and tips above help you to create sprint goals that are relevant and meaningful to the whole team, keeping them invested in each iteration as you work your way along the product roadmap.
Refer back to this page whenever you need a refresher. If you have any questions or topics you’d like me to cover, leave a comment below or send me a message through the website. Thanks for reading. See you next time!
Now, over to you, what’s your favourite Sprint Goal that you’ve come across? Please share it in the comment section below.
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 helps digital creative agencies’ leadership teams delight their clients, fulfil their people, and improve their prosperity.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.