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 to track them.
The Sprint Goal Explained
A sprint goal summarises the desired outcome of an iteration. It provides a shared objective, and it states why it’s worthwhile undertaking the sprint. Sample sprint goals are “Learn about the right user interaction for the registration feature”, or “Provide the missing reporting functionality”. Every sprint should have one shared goal. This ensures that everyone moves in the same direction. Once the goal has been selected, the team implements it. Stakeholder feedback is then used to understand if the goal
has been met, as the following picture shows.
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 relevant sprint goal helps you address the most important challenge, and it moves you closer towards your vision or release goal. For a new product or a bigger product update, the main challenge in the early sprints is to resolve uncertainty and to mitigate the key risks. To determine where the greatest risk currently is, I use the three innovation drivers – desirability, feasibility, or viability – as the following picture shows.
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.
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.
Summary
“You’ve got to be very careful if you don’t know where you are going, because you might not get there,” says Yogi Berra. Employing a sprint goal increases that chances of getting where you want to go, of creating a successful product.
Reference: Effective Sprint Goals from our JCG partner Roman Pichler at the Pichler’s blog blog.
