Photo courtesy of Rawpixel

A Template for Formulating Great Sprint Goals

Published on 11th March 2014 4 min read

Working with sprint goals is a powerful practice. But many product owners and teams don’t leverage sprint goals or don’t apply them correctly: Sprint goals often state the stories to be implemented rather than the reason for undertaking the iteration. That’s rather unfortunate: Effective sprint goals serve to test ideas, to deliver features, and to foster teamwork. This post introduces a sprint goal template to help you write powerful sprint goals to build great products.

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 its 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 for more than ten years, 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. 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 for general release.”

The sprint goal hence differs from listing the user stories that should be implemented. It communicates the reason for carrying out the work, and it provides a motivation for running the sprint. The sprint goal should be shared: The product owner and the development team should 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 form of a task board.

Learn More

Post a Comment or Ask a Question


  • 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?

    • 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 🙂

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

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

2 Trackbacks

    Warning: call_user_func() expects parameter 1 to be a valid callback, function 'blankslate_custom_pings' not found or invalid function name in /nas/content/live/romanpichler/wp-includes/class-walker-comment.php on line 179

Leave a Reply

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