The Sprint Goal is an important, but often overlooked, part of sprint planning. A good sprint goal can help you focus your work during the sprint, reduce contention between team members and stakeholders, and build a much better product increment. But how can you get it just right?
In this article you will learn:
- What is the sprint goal
- 8 reasons to take the sprint goal seriously
- 4 challenges with sprint goals and how to resolve them
- A common structure for documenting your sprint goal
This article is part of our series about sprint planning – see other articles in the series:
- Sprint planning 101
- The sprint backlog
What is a Sprint Goal?
A sprint goal is a concise statement (between one and two sentences) outlining the objective of the sprint. It lets everyone in the team know what should be accomplished during the sprint, and should supply the motivation for the sprint. The sprint goal should be agreed upon by the product owner and the development team. Both parties should believe in this shared goal and maintain that it is beneficial to strive towards this goal.
A sprint goal typically focus on one or more of the following:
- Testing assumptions about a larger development project, such as development complexity
- Deal with risks by fixing issues, modifying architecture or adding components
- Produce new features – add new stories requested by customers
8 Reasons You Should Take Sprint Goals Seriously
- The development team can discuss and track their progress in relation to the sprint goal during the sprint. This helps monitor and assess progress throughout the sprint.
- The sprint goal provides a reason for building the product increment: at the end of the sprint, the team should produce a potentially releasable product increment, in line with the sprint goal.
- A common sprint goal helps the development team set priorities, which makes it simpler to see which stories should be worked on next.
- A sprint goal promotes teamwork by encouraging a shared focus and goal and lays the foundation for efficient sprint planning.
- An informative sprint goal helps the product owner devise a product roadmap, and may provide details used in the creation of the product roadmap.
- A sprint goal promotes product backlog cohesion. It provides a focus that helps members of the team to develop features or functionality that work well together.
- A sprint goal helps stakeholders understand the aim of the sprint.
- A sprint goal promotes a coherent, focused decision-making process. The team can make more effective decisions during the sprint when they have a clear goal in mind.
How to Define a Sprint Goal
A Sprint Goal should be targeted, quantifiable, realistic, relevant and time-bound. Sprints are time-boxed iterations, so all sprint goals are time-bound. In other words, the goal must be achieved on completion of the sprint.
You should treat the sprint goal differently in the initial sprints of a release vs subsequent sprints:
- The focus of an initial sprint—An initial sprint may focus on: the ideal user experience, the software architecture, or viability. To choose the most appropriate goal, decide what risk will be detrimental if not dealt with straight away.
- Subsequent sprints—After the initial few sprints, the focus of the sprint starts to change from dealing with unknowns to finishing feature so that product release is possible. The focus then becomes obtaining quantitative data to understand the user experience. This change in focus should affect the sprint goal.
Remember that failure is part of the process. When choosing a Sprint Goal, keep in mind that all new projects involve an element of trial and error. Failure in early stages of the release contributes to long-term success.
4 Challenges With Sprint Goals and Tips for Resolving Them
1. The Sprint Goal is Too Big
At times your team may try to cram too many tasks into a sprint. Resist the temptation to take on too much in a sprint, because this will hurt your velocity and ability to deliver consistently.
2. The Sprint Goal is Vague
Often a sprint goal will be indefinite or too sketchy. Some team members or stakeholders may not fully understand the goal.
To ensure this doesn’t happen, don’t shy away from asking the question: “How will we know if we have successfully reached the Sprint Goal?” If the team has different answers to this question, or are unsure how to answer it, you should further refine the sprint goal.
Make sure that the sprint goal is measurable. This gives the team an objective framework to work with and minimizes the difference of opinion.
You should also ensure everyone on the team understands and is dedicated to the sprint goal, as this promotes team ownership.
3. The Team Doesn’t Pay Attention to the Sprint Goal During the Sprint
Sometimes the team loses interest or stops paying attention to the sprint goal.
To prevent this from happening, make the goal visible. Write the sprint goal in a prominent place, make sure it is large and in bold colors. You should encourage the team to talk about their journey towards the sprint goal. Make this part of the daily Scrum.
4. The Sprint Goal Doesn’t Feel Meaningful
At times the Sprint Goal is not business- or user-focused. Teams feel the goal is not meaningful and unrelated to the organization’s real goals. This can cause a lack of focus during the sprint and in the long term, increase the risk and cost of the entire release.
To ensure the goal is business or user-focused ask the question: “What will a user do when the team implements this product or software feature?” Your team should also aim to get feedback early on, from team members, product owners, and customer representatives.
A Common Structure You Can Use to Create a Sprint Goal
It is useful to ask the following three questions before your team selects a sprint goal:
- “Why do we need to conduct this sprint?”
- “How can we attain each goal?”
- “How do we know when a goal is achieved?
Create a document that captures your sprint goal. The document can contain four sections:
- Header
States which product, release, and sprint or iteration the goal applies to.
- The goal
The goal section addresses the “why”. Why it is useful to undertake the sprint?
When selecting a sprint goal it is useful to think about the uncertainty you face during the release. In initial sprints, you can address risks and test assumptions. In subsequent sprints, you may like to pay attention to optimizing and completing features.
- The method
The method section addresses the “how”. How will the goal be met?
A typical Scrum answer is to create a product increment using the prioritized product backlog items and prepare a demo for the stakeholders. But this is not the right answer for every release or every sprint.
Oftentimes, there are other methods to meet or demonstrate the sprint goal. For example, you may wish to create a paper prototype, carry out a usability test, or define security or compliance criteria to support the sprint goal.
You should select the most appropriate method and document it in this section. You should also decide who supplies the feedback and data; these individuals form the test group. The stakeholders will become clear once you specify the test group.
- The metrics section
The metrics section also addresses the “how”. How will you know if the goal has been attained? For example, if you decided to go with a product demo, you may decide that over two-thirds of the stakeholders should approve the new feature.
Whatever your metrics, ensure that they provide you with the information you need to be confident you have achieved the goal.
Focusing Sprint Goals on Quality
The pressures of agile development often lead us to define a sprint goal in terms of developing new features or preparing the infrastructure for those new features. Agile teams rarely have the luxury of devoting an entire sprint, or significant parts of it, to improving product quality. We call this “reactive maintenance” – ignoring quality issues until something goes terribly wrong.
This mindset needs to change. Data and experience show that reactive maintenance can dramatically reduce developer productivity. Dealing with quality issues early can be easy and cost-effective, while production issues can be complex and draining for software development teams.
To learn how to avoid the reactive maintenance mindset and start dealing with quality issues on time, read our white paper: Reactive Maintenance – the Silent Killer of Developer Productivity.