Working with a sprint goal is a powerful agile practice. This post helps you understand what sprint goals are, why they matter, hand you can write and 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”. If you use a product goal, then each sprint goal should be a step towards this overarching objective.
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.
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, Facilitates Teamwork, and Guides the Development Team
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 Effective Sprint Goals
Like any operational goal, a sprint goal should be SMART: specific, measurable, agreed upon, realtistic, 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 example, 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 realistic. 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.
Last but not least, make sure that all development team members agree to the sprint goal. As the product owner, you should never try to force a sprint goal onto the team or persuade the members to follow it. Otherwise, the development team will hardly be motivated to do their best to reach the goal. The minimal buy-in you should seek on the sprint goal is consent. This means that nobody objects to it; everybody is ok with it.
Visualising and Tracking the Sprint Goal
I find it helpful to visualise the spirn goal to keep it present and visible. One way to do this is to add it to the sprint backlog or task board, as the picture below illustrates
The picture above shows a simple, physical sprint backlog with four columns: The high-priority items to be implemented, the tasks that have to be carried out, the tasks that are in progress, and the tasks that are done. The sprint goal is attached to the first column thereby directing and focusing the entire sprint backlog.
Post a Comment or Ask a Question
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!
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!
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?
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!
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!
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.
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.
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?
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!