I find it helpful to consider three questions when choosing a sprint goal: Why do we carry out the sprint? How do we reach the desired goal? And how do we know that the goal has been met? My sprint goal template therefore consists of three main parts: the actual goal, the method employed to reach the goal, and the metrics to determine if the goal has been met. It additionally provides a header section that allows you to state to which product and sprint the goal belongs, as the picture below shows. You can download the template as a PDF from romanpichler.com/tools/sprint-goal-template/ or by clicking on the image below.
The template above has grown out of my experience of working with Scrum, and it is inspired by the scientific method. Let’s have a look at the template sections in more detail.
The goal section states why it is worthwhile to undertake the sprint. You can think of the goal as the outcome you want to achieve with the sprint and the benefit you’d like to create. Examples are:
The sprint goal hence differs from the user stories that should be implemented. It communicates the reason for carrying out the work, and it provides purpose and motivation for running the sprint. The sprint goal should be shared: The Scrum product owner and the development team should agree on the goal and believe that working towards the goal is the right thing to do.
To choose the right sprint goal I find it helpful to consider the amount of uncertainty present. In the early sprints, addressing risks and testing assumptions allows me to learn about what the product should look like and do and how it is built. Once the key risks and critical assumptions have been dealt with, I like to focus on completing and optimising features, as the following picture shows:
This section addresses the question of how the goal is met. The default Scrum answer is simple: Create a (potentially shippable) product increment using the high-priority product backlog items, and demo it to the stakeholders in the sprint review meeting. But writing software and employing a product demo are not always the best methods to achieve the goal. A paper prototype can be good enough to test a visual design idea or an assumption about the user interaction, for instance. What’s more, other methods such as carrying out a usability test or releasing software to run an A/B test may well be more effective than a product demo. You should therefore carefully choose the right method and state it in this section.
But don’t stop there. Determine the test group, the people who should provide feedback and data. Who these individuals are depends on the sprint goal: If you are validating an assumption about the visual design, the user interaction or the product functionality, then you probably want to collect feedback and data from the users. But if you are addressing a technical risk, then users may not be able to help you. Consider inviting a senior developer or architect from another team instead. Stating the test group clarifies who “the stakeholders” are, who is required to provide feedback so that the right product is developed.
The metrics section communicates how you determine if the goal has been met. Which metrics you use depends on the method chosen. For a product demo, you may state that at least two thirds of the stakeholders present should respond positively to the new feature, for instance; for a usability test, at least three of the five testers are complete the task successfully in less than a minute; and for the release of a new feature, you might say that at least 80% of the users use the new functionality at least once within five days after launching the feature.
Whichever metrics you choose, make sure that they allow you to understand if and to which extent you have met the goal.
The header section consists of the two subsections “Product” and “Sprint”. They simply allow you to state which product and which sprint the goal belongs to.
Customise this section according to your needs. If you work for an agencies or an IT solution provider, you could replace “Product” with “Project”, for instance.
You may be wondering how the template relates to the user stories. Let me first reiterate that your sprint goal should differ from your user stories. The goal explains the why it is a good idea to carry out the sprint an implement the stories. The user stories enable you to reach the goal. It’s a common mistake to confuse the two.
To connect the template and the stories you have two options: You can state the relevant user stories in the template’s method section, or you can list them separately on the sprint backlog, as the following picture illustrates.
In the picture above, the sprint goal is stated on the left to the sprint backlog, which lists the user stories and the tasks required to meet the goal in the form of a task board.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
You correctly say that the sprint goal should contain the why behind the user stories. But as you mention in the article, releasing a feature, for instance: “Get the reporting feature for general release,” can be a sprint goal. I think the why behind the release should be the sprint goal, the why that team created and released the feature.
Thank you.
Thanks for your comment, Ali. You are right: A sprint goal should clearly communicate the purpose of running a sprint. A better way to phrase a release-related goal might be "Get the reporting feature ready so users can start creating reports."
Hello Roman,
Really insightful articles and I really enjoyed your blog article about the Sprint Goal. I am working in a global SAP Hana program (Greenfield) and the product backlog is split amongst 6 workstreams each with their portion of the backlog. They work on independent PI Sprints and Sprint Goals. Is this OK?
Thanks for sharing your feedback and question Jacques. I am not a SAFe expert and hence not the best person to answer your question unfortunately. But I find it very useful to set a product goal for the next, say, two to three months and use it to discover the right sprint goals, as I discuss in more details in the following two articles:
Hope this helps!
Hi Roman,
Thank you for the template. I read this article multiple times and I also ran a workshop "Crafting sprint goal" for one of my Scrum teams. It went well.
One of the key things I would like to convey to other readers/practitioners is: "We should get rid of the mindset that all increments are build to be released sooner or later. Some of them are planned to validate the assumptions, sometimes by the Scrum team itself and sometimes via the feedback of stakeholders".
Correct me if my experience is not valid.
Regards,
Biplab
Thanks for sharing your experience and thoughts Biplab. I am glad that setting a sprint goal worked well for one of your teams. I agree that an early product increment may not be releasable. Hence the term "potentially shippable product increment" is sometimes used. I also agree that especially early sprints may focus on validating assumptions, addressing risks, and acquiring the relevant knowledge rather than building and releasing functionality. But I would also encourage you to ensure that you understand the product value proposition, target group, key features, and business goals as well as the product goal you want to meet before you formulate a sprint goal and run a sprint. To out it differently, carry out the necessary product discovery and strategy validation work. (See my article A Brief Guide to Product Discovery for more information.) Hope this helps!
Hi Roman,
Thanks for the very insightful article.
I am a Scrum Master of a team developing a back-office banking product, which we deliver in small increments. However, we struggle to create a coherent Sprint Goal because of the different expertise of team members. The process of clarifying the requirement, preparing the backend and then the frontend for a feature never fits into the two weeks of the sprint.
We have tried slicing features as small as possible, and creating a Sprint Goal that is addressed by the majority of the work, but some developers would always work on something else that won’t contribute to the goal.
What would you advise in this situation?
Many thanks for your feedback!
Kay
Hi Kay, Thank you for sharing your feedback and question. It seems to me that you've already stated two possible improvement measures, strengthen the skills of the team members and reduce the amount of time members spend on activities that are not related to the sprint goal. You might achieve the former by training people and by encouraging the team to practice pair programming. The latter might be realised by ensuring that everyone is fully committed to the sprint goal and that people are not asked to carry out any other work. Additionally, ensure that the high-priority items are ready when you start the sprint planning meeting, and that (some of) the team members are involved on the refinement work. Finally, discuss the issue and its causes in one of your next sprint retrospectives and involve the team members in choosing the improvements you want to try. Hope this help!
How many goals are typically created for a sprint? We are using agile for a developer advocacy teams.
Hi Aaron, The standard recommendation in Scrum is to have one sprint goal per sprint that everyone works towards. This creates are a shared purpose and an incentive to collaborate, and it makes it easier to track progress towards the goal and determine if it has been met. Hope this helps!
Hello great Roman Pichler, first of all I want to thank you for writing these amazing articles on scrum, this has helped me a lot.
I am contacting you because I wrote an article in Brazil to help other people to learn scrum and I made a quote to your content here, there I put all the steps you teach and made reference to your blog.
I hope you do not mind. Once again, thank you very much!!
Thanks for sharing your feedback Mauricio and the article. Looks nice. I appreciate that you linked back to my work :)
Hi Roman,
Thanks for the insightful article. I'd like to try this for the teams I am coaching though need further inspiration around it. The teams are presently part of a bigger system and presently supporting as complicated subsystem team. They are presently driven by various projects (with milestones to release every two months) and work on them simultaneously in same sprint. The coherency amongst the stories in a sprint is not there and hence they try to craft a goal for the slice of project getting implemented in a sprint and clubbed these together to call a sprint goal. The PO wants to realize part of functionality he committed to the respective project managers in the upcoming release and hence encourage to take stories for all projects in same sprint. Do you have any suggestion to improve the way the planning is done so that it will more focused sprint goal can be created?
Regards,
Rajat
Thank you for your feedback and question Rajat. I recommend that you focus the team on one product/project per sprint. This will make it easier to identify a meaningful sprint goal. As long as the team members work on several projects at once, you will struggle to create one, shared, and helpful sprint goal in my experience. Hope this helps and good luck!
Hi Roman.
First of all thanks for a really inspiring article. I'm having trouble however of "mapping" your ideas onto my current environment. I'm currently working as a Scrum Master in a SAFe program. At the start of the PI Planning program management gives us an overview of the features we need to implement, without really elaborating too much as to what the actual user needs are, where the requirements came from, how they will benefit the user/customer, etc. It's pretty much "this is what we have to do, now go and plan". So then we plan the work for the 5 sprints that comprise the PI, which is pretty much distributing the workload (user stories) among the aforementioned sprints. The primary goal is to try and deliver everything that is planned for the PI, the line between particular sprints gets really blurry and the sprints themselves stop being a representation of the increment of potentially deliverable software but just a time frame to complete a portion of work. When asked what is our sprint goal, nobody in the team, POs included, has really any kind of idea because we know it doesn't really matter to anyone, we're not going to be deploying these changes anyway. So trying to come up with a proper sprint goal feels very forced and unwanted. There is the tendency to just rephrase the names of the stories in a way that you have a full, logically sounding sentence and that's it. Any thoughts or suggestions?
Hi Tomasz,
Thank you for sharing your feedback and question. I am not a SAFe expert but based on what you have told me, I believe you have two options: First, don't use sprint goals and focus on delivering a set of user stories instead. Second, use sprint goals but ask management to provide you not only with a set of features but also a product goal. This golas should describe the desired outcome you want to achieve by implementing the features. Then break the product goal into a series of sprint goals. Assign the features to the sprint goals and start breaking them into epics and user stories as needed.
Does this help?
Hi Roman,
Nice template! Question for you? Will it not be tough if you run 2 weeks sprint to both implement a solution and have time to validate the goal is met according to a metric? Should the the hypothesis be confirmed and that is the success criteria of the sprint or is it enough to create the possibility to test the hypothesis. Hope my questions is clear.
Thanks,
Haz
Thanks for sharing your feedback and question Haz. If it's possible to validate the sprint goal within the sprint timebox depends on the validation technique used. Say your goal is to test if users are willing to share personal information before properly using a healthy eating app. If you now employ a method like a product demo and usability test that generates instant feedback, then the answer to your question is likely to be yes. Otherwise, you may need a few days to collect the relevant data before you can determine if people are willing to share their data, for example, by releasing an early product increment to selected users. Does this help?
Thank you for this excellent information. Our organization has divided our developers into 3 teams: Product, Professional Services, and Break/Fix Support. I am the "scrum master" of the Break/Fix Support team -- and new to this. I understand from my reading that Scrum for Maintenance can be challenging. Our team is even more so; we have to do bug/defect fixes for 13 different customers, using a total of 15 systems of our product. Additionally, the systems for each of the customers have been tailored to their business needs. Our support development team is comprised of programmers of varying skill levels, who have all worked on the product development or professional services work for some of these customers. Our organization has mandated that we implement 10-day sprints. Bug/Defect tickets included in the sprint are an amalgamation of all of the customers based on a percentage of the time available for all developers during the sprint period. I think that it goes without saying further that we have a complex scenario.
I have ideas on handling many of these challenges, and am researching the heck out of how best to handle this, which is what brought me to your articles.
Do you have recommendations on how to generate sprint goals and metrics for our sprints? My inclination is to have sprint goals for each system; however, the thought of 13-15 sprint goals and metrics is daunting. It is seems impossible to capture the goals of all of our proposed work with one sprint goal and set of metrics.
I appreciate any advice that you can offer!
Hi Ami,
Thank you for your feedback and question. I recommend reviewing if Scrum is the right process for bug fixing work for you. You may be better off using a Janban-based process instead. The following articles should help you with your decision:
When Scrum is not a Good Fit
Is Scrum Right for Your Product?
Succeeding with Innovation and Maintenance
As a longer-term solution, you might want to explore if it is beneficial to ask the development teams to take on (some of) the bug fixing work. This can lead to improved quality and reduced technical debt.
Hope this helps!