Photo courtesy of Rawpixel

A Template for Formulating Great Sprint Goals

Published on 11th March 2014 Last Updated on: 29 Apr 2024

Sprint goals can guide the work of the development team and describe the desired outcome of a sprint. As useful as they are, sprint goals are not always correctly applied: They often reiterate the user stories to be implemented rather than the reason for running the sprint. This article introduces my sprint goal template and it explains how you can apply it to take full advantage of sprint goals .

Overview of the Sprint Goal Template

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 or by clicking on the image below.

Roman's Sprint Goal Template

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

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:

  • Test an assumption about the user interaction and learn what works best for the user, for instance: “Will users be willing to register before using the product features?”
  • Address a technical risk such as: “Does the architecture enable the desired performance?”
  • Release a feature, for instance: “Get the reporting feature ready so users can start creating reports.”

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:

How to choose the right sprint goal

The Method Section

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

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

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.

Sprint Goal, User Stories, and Sprint Backlog

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.

Sprint goal and sprint backlog

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.

Post a Comment or Ask a Question


  • ali khabbaz says:

    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.

    • Roman Pichler Roman Pichler says:

      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.”

  • Jacques BERTRAND says:

    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?

  • Biplab Subedi says:

    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.


    • Roman Pichler Roman Pichler says:

      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!

  • Kay says:

    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!


    • Roman Pichler Roman Pichler says:

      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!

  • aaron ralls says:

    How many goals are typically created for a sprint? We are using agile for a developer advocacy teams.

    • Roman Pichler Roman Pichler says:

      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!

  • Mauricio Lima says:

    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!!

    • Roman Pichler Roman Pichler says:

      Thanks for sharing your feedback Mauricio and the article. Looks nice. I appreciate that you linked back to my work 🙂

  • Rajat Das says:

    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?


    • Roman Pichler Roman Pichler says:

      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!

  • Tomasz says:

    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?

    • Roman Pichler Roman Pichler says:

      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?

  • Haz says:

    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.


    • Roman Pichler Roman Pichler says:

      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?

  • Ami Chancellor Phillips says:

    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!

  • Himadri Debnath says:

    Thank you Roman ! I am truly happy to get your valuable insights and advice in this regards. I believe this is great privilege for me to discuss and exchange ideas related to Scrum and getting your expert advice and thoughts to clear my doubts … You have taken your valuable time to respond my query and I am really grateful for that. Thanks again.

    Just one more point : I want to read ALL OF YOUR BLOGS/ARTICLES related to SCRUM. If you can just provide me the pointers / links from where I can start?

    Many Many Thanks again Roman. Take care!

    Himadri Debnath

    • Roman Pichler Roman Pichler says:

      You’re very welcome Himadri. I am glad that you found my suggestions helpful. To read all my Scrum-related articles, please search on the blog for “Scrum” (the search box is on the main blog page) or simply browse through the process blog post category (accessible via the website menu and the main blog page). Happy reading!

  • Himadri Debnath says:

    Hi Roman
    I love your blog and your templates.

    Just one question: I am new to Scrum/Agile world and while working in the project where product is mature enough , we are working mainly on maintenance stuff. I can see that the PO is just collecting few items from end users here and there and providing us a bunch of requirement collection which does not have any interrelation. As we are running monthly sprints with 6 team members , just to fill the capacity , PO is providing these volume of work and no Goal , though we are working on the same product.

    Could you please advise what best course of action I can take as a scrum master and how to use the template here to figure out the sprint goal.

    Many thanks in advance !!

    • Roman Pichler Roman Pichler says:

      Thank you for sharing your feedback and question Himadri. When you work on a mature product that requires incremental enhancements and bug fixes, finding effective sprint goals can be hard. This is due to the fact that Scrum is great for developing complex products but less well suited for mature offerings, as I discuss in the article “Is Scrum Right for Your Product?“. But you can still use goals to focus the work of the dev team. For example, you might want to improve a certain feature in one sprint and another focus on bug fixing in the next one. Does this help?

  • Oscar NIYONKURU says:

    Hi Roman

    I love your blog and your templates.

    Just one question: in METRICS section, is it allowed to use burn-up or burn-down charts as progress measurements tools? Cumulative Flow Diagram?

    Or performance test methods to use in order to measure the response time? Or responsiveness of a user story?

    • Roman Pichler Roman Pichler says:

      Thank you for sharing your feedback and question Oscar. The metrics section on my sprint goal template encourages you to:

      • Choose a goal that is measurable and
      • Consider how you going to determine if the goal has been met.

      Say you are building a new healthy eating app. You believe that users would be willing to share personal data like age, weight, and dietary requirements as part of the initial set-up process. But as you are not sure, you want to test this assumption in the upcoming sprint. Having chosen the goal, you should also consider how you will determine if the goal has been met. Say that you decide to invite selected users and employ a product demo. How many people will then have to positively respond to sharing their personal data to consider the goal met? More than half, two thirds, or even 80%?

      The metrics section therefore states the success criteria to determine if the goal has been met or not. A tool like the sprint burndown chart might be used by the development team to track progress towards the goal. It helps the team understand if the product increment will be available at the end of the sprint as planned.

      Hope this helps!

  • Riya Badlani says:

    Really good article, those who are starting the journey in Agile Transformation.

  • Brian Sørensen says:

    I am a product owner for a service now (itsm) delivery team. I believe the sprint goal template is easy to view, but harder to execute.

    In Service Now we have 13 different components having a different purpose and hence the user stories within them have different focus.

    I am struggling to execute how I should formulate the goal, method and metrics. How would you go about formulating goals, methods and metrics when you have different directed stakeholders and components?

    Looking forward for a helping hand 🙂

    • Roman Pichler Roman Pichler says:

      Hi Brian,

      Thanks for your feedback and sharing your question. I suspect that you find it hard to formulate one shared sprint goal because your team works on different components with a different purpose in each sprint. If that’s something you can’t or don’t want to change, then that’s ok. But it makes little sense to use a sprint goal in this case IMO.

      If you want to take advantage of effective sprint goals and their benefits, then start by considering if the components belong to the same product or not. As a rule of thumb, a team should work on one product per sprint. This reduces task-switching, fosters collaboration, and increases productivity.

      Next, ask yourself what you need to accomplish in the next sprint, which outcome you want to achieve. That should make a good candidate for the sprint goal. Then ask yourself, how you will be able to tell if you have met the goal, which will give you the relevant metrics. If you plan to develop a product increment and demo it (as it is the default in Scrum), you don’t have to worry about about the method section. If you were to use a mock-up and usability test instead, for example, you may want to state this in the section.

      Does this help?

  • Frans says:

    Hi Roman,

    I recently noticed this post and downloaded the tempIate. I was wondering, is there a distinction in which role should fill in each section? From my perspective the Goal and Metrics section can be filled in by the Product Owner / (Product Manager). The Method section can be filled in mainly by or in co-operation with the solution development team. How do you see it?

    Thanks for your reply.

    • Roman Pichler Roman Pichler says:

      Thanks for your question Frans. I prefer a collaborative approach where product owner and team jointly discuss and set the sprint goal. Ultimately, everyone has to be reasonably happy with the goal and feel that it is meaningful. The same is true for the method and the metrics. Product owner and team should figure out together how the goal can be met and what the success criteria are. I therefore recommend that you fill out the sprint goal template as part of the product backlog management (aka grooming or refinement) work. Hope this helps!

  • Florian says:

    I always enjoy the simple, but highly effective templates by you, Roman. Thank you.

Leave a Reply

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

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.