Photo courtesy of Pexels

Creating Effective Sprint Goals

Published on 11th December 2012

Last Updated on: October 11, 2019

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

10 Comments

  • Fredrik says:

    Thanks for this Roman – it was an informative read.

    The development team I am a part of are in the process of revising our way of work to put our sprint goal at the very forefront of what we are doing. This goal will capture an important business problem or outcome we want to achieve. It will be solution agnostic and have a wide solution space.

    “Refinement” will be creating a shared understanding around the problems we are planning to solve and discussing high level solution candidates we might pursue. We will not formally size beforehand nor have a strict definition of ready. Slicing items to reduce scope and optimize value will be done inside the sprint itself.

    The reasoning is to avoid feature factory thinking, where features/solutions are defined in detail upfront and engineers have often limited opportunity to influence them – we would like to focus on creatively and collaboratively solving well defined problems in a cross-functional effort. All inside the sprint.

    Do you have any experience or learnings with this kind of approach? Would love to hear any input or feedback you may have. Thanks!

    • Roman Pichler says:

      Thank you for sharing your feedback and approach Frederik. Sounds interesting! I am wondering if you are combining the product goal and the sprint into one objective. Personally, I would prefer to keep them separate, and I am happy to work with sprint goals that are solution-focused–as the corresponding product goal described the desired outcome or benefit that the product should create. Please take a look at my articles “Leading Through Shared Goals” and “Product Goals in Scrum.” Hope this helps and good luck with choosing the right sprint goals!

  • Andreas Hansen says:

    Hello Roman.

    Thank you for a very insightful post on the sprint goal. I find it difficult to get my team to value and actively use sprint goals. I think it has to do with the nature of their work. They develop automated solutions of manual processes for customer service systems mainly through the use of RPA software. Therefore we mostly have sprints where they work on different non-related solutions. This is because we prefer that our solutions aren’t too complex, and that our different customers often requests more solutions to our backlog. So we want to deliver each solution quickly. This makes it hard to formulate a common (simple) goal covering most of the sprints work. Therefore, our sprint goal mainly consists of meeting the acceptance criteria on the top user stories of the sprint.

    Do you have any advice on how we can use the sprint goal?

    • Roman Pichler says:

      Thank you for your feedback and question Andreas. In order to effectively use sprint goals, you would have to experiment with working on product/solution per sprint and possibly running shorter sprints. In addition to strengthening teamwork, this approach should also increase the productivity of the team, assuming that team members currently switch between products/solution in a single sprint. Hope this helps!

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

    Regards,
    Julian

    • Roman Pichler says:

      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.

    regards

    Ravi Singh
    imravisingh@gmail.com

    • Roman Pichler says:

      Hi Ravi,

      Thank your for your feedback and sharing your experience. I don’t want to discourage you from using Scrum, but the scenario you describe might lend itself better to a Kanban-based process–maybe something to consider and experiment with. I’ve written about the difference between the two approaches in Is Scrum Right for Your Product? and When Scrum is not a Good Fit.

      Best wishes!

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

    • Roman Pichler says:

      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

  • Fredrik says:

    Thanks for this Roman – it was an informative read.

    The development team I am a part of are in the process of revising our way of work to put our sprint goal at the very forefront of what we are doing. This goal will capture an important business problem or outcome we want to achieve. It will be solution agnostic and have a wide solution space.

    “Refinement” will be creating a shared understanding around the problems we are planning to solve and discussing high level solution candidates we might pursue. We will not formally size beforehand nor have a strict definition of ready. Slicing items to reduce scope and optimize value will be done inside the sprint itself.

    The reasoning is to avoid feature factory thinking, where features/solutions are defined in detail upfront and engineers have often limited opportunity to influence them – we would like to focus on creatively and collaboratively solving well defined problems in a cross-functional effort. All inside the sprint.

    Do you have any experience or learnings with this kind of approach? Would love to hear any input or feedback you may have. Thanks!

    • Roman Pichler says:

      Thank you for sharing your feedback and approach Frederik. Sounds interesting! I am wondering if you are combining the product goal and the sprint into one objective. Personally, I would prefer to keep them separate, and I am happy to work with sprint goals that are solution-focused–as the corresponding product goal described the desired outcome or benefit that the product should create. Please take a look at my articles “Leading Through Shared Goals” and “Product Goals in Scrum.” Hope this helps and good luck with choosing the right sprint goals!

  • Andreas Hansen says:

    Hello Roman.

    Thank you for a very insightful post on the sprint goal. I find it difficult to get my team to value and actively use sprint goals. I think it has to do with the nature of their work. They develop automated solutions of manual processes for customer service systems mainly through the use of RPA software. Therefore we mostly have sprints where they work on different non-related solutions. This is because we prefer that our solutions aren’t too complex, and that our different customers often requests more solutions to our backlog. So we want to deliver each solution quickly. This makes it hard to formulate a common (simple) goal covering most of the sprints work. Therefore, our sprint goal mainly consists of meeting the acceptance criteria on the top user stories of the sprint.

    Do you have any advice on how we can use the sprint goal?

    • Roman Pichler says:

      Thank you for your feedback and question Andreas. In order to effectively use sprint goals, you would have to experiment with working on product/solution per sprint and possibly running shorter sprints. In addition to strengthening teamwork, this approach should also increase the productivity of the team, assuming that team members currently switch between products/solution in a single sprint. Hope this helps!

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

    Regards,
    Julian

    • Roman Pichler says:

      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.

    regards

    Ravi Singh
    imravisingh@gmail.com

    • Roman Pichler says:

      Hi Ravi,

      Thank your for your feedback and sharing your experience. I don’t want to discourage you from using Scrum, but the scenario you describe might lend itself better to a Kanban-based process–maybe something to consider and experiment with. I’ve written about the difference between the two approaches in Is Scrum Right for Your Product? and When Scrum is not a Good Fit.

      Best wishes!

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

    • Roman Pichler says:

      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!

  • The Product Owner Responsibilities says:

    […] Determine what needs to be done next and select the right sprint goal. […]

  • Get your Focus Right: : Learning and Execution in Scrum says:

    […] distinguishing between learning and execution helps you […] choose the right sprint goals. […]

  • Good post on often unused sprint goal | Agilistas Unite! says:

    […] Good post on often unused sprint goal Share this:TwitterFacebookLike this:Like Loading… This entry was posted in Uncategorized by sbargon. Bookmark the permalink. […]

  • How to Create your Initial Product Canvas says:

    […] See my post “Effective Sprint Goals” for more information on choosing the right goal or hypothesis. […]

  • The Product Owner's Guide to Effective Sprint Goals | Agile best practices | Scoop.it says:

    […] This post helps product owners understand what sprint goals are, why they matter, how to write and how to track them.  […]

  • The Product Demo as an Agile Market Research Method says:

    […] Your sprint goal should help you […]

  • A Product Canvas for Agile Product Management says:

    […] necessary to reach the sprint goal […]

  • The Product Owner’s Guide to Effective Sprint Goals – Abir Roy says:

    […] on www.romanpichler.com Share this:TwitterFacebookLike this:LikeBe the first to like this. Posted on January 14, 2013 by […]

  • The Product Owner's Guide to Effective Sprint Goals | All about Web | Scoop.it says:

    […] This post helps product owners understand what sprint goals are, why they matter, how to write and how to track them.  […]

  • Was das Sprint-Ziel aus Scrum mit der GP 2.1.1 aus Automotive SPICE® zu tun hat | Sebastian Schneider: Automotive Agile, Funktionale Sicherheit und Automotive SPICE says:

    […] Bugs bis zu bestimmten benutzererlebbaren Features so ziemlich alles sein. Auf den Seiten von Roman Pichler habe ich ein sehr schönes Beispiel über die Granularität der Sprint-Ziele gelesen. Er […]

  • +Jared Owens this may have some good ideas for our group | Tyler Merrick says:

    […] The Product Owner’s Guide to Effective Sprint Goals This post helps product owners understand what sprint goals are, why they matter, how to write and how to track them. […]

  • Five Steps to Successfully Groom your Product Backlog says:

    […] For new products or innovative features, your goal should be a testable hypothesis […]

  • The Scrum Cycle: Resolving Uncertainty Through Focussed Experiments says:

    […] the first step of the cycle, product owner and team select a sprint goal […]

  • Epics and Ready Stories says:

    […] Then I select the goal of the next sprint – either to address the most critical risk and/or to deliver functionality to the stakeholders […]

Leave a Reply to Julian Bayer Cancel reply

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