Photo courtesy of Pexels

Creating Effective Sprint Goals

Published on 11th December 2012

Working with a sprint goal is a powerful agile practice. This post helps you understand what sprint goals are, why they matter, how to write and how to track them.

The Sprint Goal Explained

A sprint goal describes the purpose of a sprint. It provides a shared objective, and states why it’s worthwhile undertaking the sprint. Sample sprint goals are “Learn about the right user interaction for the registration feature” and “Make the reporting feature available to the users”.

As a rule of thumb, teams should work with one shared goal. This ensures that everyone moves in the same direction. Once the goal has been selected, the team implements it. Check at the end of the sprint if the goal has been met. Say you want to learn if users are willing to register as the first step in the user journey. Then use the product demo or a usability test at the end of the sprint to validate if you have met the goal and understand if it’s OK to ask people to register first or if this creates a barrier to adoption.

Sprint Goal Benefits

I have found that working with a sprint goal has five main benefits, particularly for new products and new features: It facilitates prioritisation and effective teamwork; it makes it easier to obtain and analyse feedback; and it helps with stakeholder communication.

Supports Prioritisation

A shared sprint goal facilitates prioritisation: It makes it easier to determine which stories should be worked on in the next cycle. Here is how I do it: I first select the goal. Then I explore which epics have to contribute to it, and I break out small detailed stories from the epics. Finally, I order the new ready stories based on their contribution to the goal.

Creates Focus and Facilitates Teamwork

Sprint goals create focus, facilitate teamwork, and provide the basis an effective sprint planning session. A shared objective guides the development work, encourages creativity, and enables commitment. Teams don’t commit to individual stories in Scrum; they commit to the sprint goal.

Helps Obtain Relevant Feedback

Employing a sprint goal makes it easier to collect the right feedback. If the goal is to evaluate the user experience, for instance, then it is desirable to collect feedback from actual target users. User representatives should therefore attend the sprint review meeting. But if the goal is to reduce technical risk by evaluating different object-relational mapping tools, then it is probably more appropriate to invite an experienced developer or architect from another team to discuss the solution.

Makes it Easier to Analyse the Feedback

Working with a sprint goal helps analyse the feedback obtained. If the team works on several unrelated stories in the same sprint then it can be tricky to relate the feedback to the right user story. This makes it harder to understand if the right product with the right features is being built.

Supports Stakeholder Communication

Finally, imagine meeting the big boss in the elevator and being asked what you are working on. Chances are that without a sprint goal, the boss will be bored to death, jump onto a specific story, or he will have left the elevator before you are finished listing all the things you do. Using a sprint goal helps you communicate the objective of the sprint to the stakeholders. This allows them to understand what the sprint is about and to decide if they should attend the next sprint review meeting.

Writing Great Sprint Goals

Like any operational goal, a sprint goal should be SMART: specific, measurable, attainable, relevant, and time-bound. As sprints are time-boxed iterations, every sprint goal is naturally time-bound: It has to be reached by the end of the sprint.

A sample goal of an early sprint is to learn more about the desired user experience (a desirability aspect), the software architecture (feasibility), or the pricing model (viability). To pick the right goal, choose the risk that is likely to hurt you most if it is not addressed immediately.

When selecting your sprint goal, remember that trying out new things requires failure. Failure creates the empirical data required to make informed assumptions about what should and can be done next. Failing early helps you succeed in the long term.

After you have run a few sprints, the emphasis usually starts to shift from resolving uncertainty to completing features so that they can be released – at least to selected users. This allows you to gather quantitative data and to understand how users employ your product in its target environment. The shift should be reflected in your sprint goal, which now focuses on “getting stuff done” rather than testing ideas, as the picture below illustrates. (I explain this development in more detail in my post “Get Your Focus Right“.)

Employing a specific and measurable sprint goal allows you to determine success. For instance, don’t just state “Create a prototype” as your sprint goal. Be explicit about the type and its purpose. Say instead: “Create a paper prototype of the user registration feature to test our user interaction ideas.”

The default mechanism in Scrum to determine success is to analyse the stakeholder feedback. Scrum suggests that the feedback should be obtained in the sprint review meeting by presenting the product increment. If this is not appropriate for you, then I suggest you make your approach explicit in your sprint goal. Write, for instance: “Test the user interaction design of the registration feature by conducting a user test in the sprint review meeting.”

Carrying out sprint planning activities ensures that the sprint goal is attainable. Traditionally, this involves selecting user stories that are required to reach the goal until the team’s capacity has been consumed. Sprint planning hence allows the product owner and the team to understand if the goal chosen can be reached. This helps you to invite the right stakeholders and be confident that they can provide meaningful feedback. Unrealistic sprint goals waste the stakeholders’ time and undermine their willingness to participate in the process.

Visualising and Tracking the Sprint Goal

To ensure that the sprint goal is fully leveraged, I visualise it. My Product Canvas tool contains a ready section with items for the next sprint, as the picture below shows. I place the sprint goal at the top of the ready section, and I determine the stories required to reach the goal. These are then listed underneath the goal.

As part of creating the task board or sprint backlog, I move the sprint goal from the product canvas onto the board. This helps ensure that the team keeps the goal in mind when implementing the individual stories.

Post a Comment or Ask a Question


  • Julian Bayer says:

    Hi Roman,

    thank you for this insightful post on sprint goals. Maybe you have some advice for my team and me.

    In Scrum Master Training, I learned that the team should do a forecast of the work it can achieve in the sprint. A sprint goal is then worked out by the Scrum Team, following which some PBIs that were forecasted for the sprint may be exchanged for PBIs which better match the Sprint Goal.

    So far, so good… In practice however, we’re having some difficulties. The most pressing of which is how to make the Sprint Goal measurable. As I understand it, in order to be an actual goal, there must be some criteria with which to evaluate whether or not the goal has been met at the end of the Sprint. For some time now, we’ve sort of picked the most important acceptance criteria of the PBIs that were forecasted and put them down. But in essence, that’s only marginally better than defining the sprint goal as “finishing all the selected PBIs”, which is exactly what we don’t want as a sprint goal.

    So, my question is this: How does a Scrum Team arrive at criteria it can use to inspect whether or not the Sprint Goal has been met at the end of the sprint? Do any of you have some real-life examples of good and measurable sprint goals?


    • Hi Julian, Thanks for sharing your question. To determine the right criteria, ask yourself how you can tell if the sprint goal has been achieved or not. You may want to try my sprint goal template, which encourages you to explicitly state the metrics for a sprint goal. Hope this helps!

  • Ravi Singh says:

    HI Roman
    First of all i want to thank you for your article on Sprint Goals.
    I wanted to add 2 cents from my recent experience. Your article focuses on a sprint where all the work is building towards a singular sprint goal, while in my case, my team works on multiple often unrelated features, as a result in my case, we have to have multiple sprint goals (one for each epic which is often different for each project).
    Although, we do similar work, we work with multiple partner applications, where we provide hosting on our common portal, as a result our projects impact different partners differently. Each sprint has a different set of partners impacted differently depending upon their needs, hence our features impact different partner applications different. The natural flow is to have different features flow into Epics and their relevant user stories. This results into a stage for multiple sprint goals based on which application feature we are working on at any time.

    The above is a multi project based sprint approach which we follow, as a result we set a stage during our spring planning for many sprint goals depending upon which project we are working.


    Ravi Singh

  • Reme Pullicar says:

    Roman, Thanks for the in-depth. I was rereading the SCRUM Guide and realized that I wasn’t too firm on the concept of a sprint goal. You’ve illustrated it well and shined light into some dark corners of my understanding. If I may make one suggestion, please add a couple lines about the relationship between sprint goals. Clearly, if we are picking user stories from Epics, several related sprints might have very similar sounding goals. Also, I’m curious, how common is an Epic simply chosen as a goal?

    • Hi Reme,

      Thanks for your comments. Sprint goals should build on each other so that each goal “moves you closer towards your vision or release goal”.

      It’s a common mistake to confuse the sprint goal, which is the purpose of the sprint, with the user stories, which describe the deliverables. The goal should answer the why it is worthwhile to carry out the sprint. The user stories (and other requirements) describe what needs to be done to achieve the goal.

      Hope this helps!

14 Trackbacks

Leave a Reply

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

Have you seen Roman's NEW BOOK?

Take a look