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.
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, 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.
