The Art and Science of Writing Sprint Goals
There is a common expression that doing <x> is part art, and part science. I would say that an example of an activity that falls under that category is the nature of the interactions that occur when writing Sprint Goals, along with consultation of the data sources, artifacts and other forms of evidence that might make sense in any given team’s context. Let’s start by understanding the general context behind Sprint Goals as articulated in the Scrum Guide.
What the Scrum Guide says About Sprint Goals
In the section of the Scrum Guide that talks about Scrum Artifacts, it describes three commitments, where each commitment is associated with one of those Artifacts:
- Product Backlog. Commitment = Product Goal
- Sprint Backlog. Commitment = Sprint Goal
- Increment. Commitment = Definition of Done
Note: The Product Goal was introduced in the most recent update (November 2020) to the Scrum Guide. The articulation of these three commitments and their relationship to each of the three Artifacts was also part of the set of modifications made at that time.
Sprint Goals in Detail
As articulated in the Scrum Guide:
“The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.”
Let’s take a deeper dive into each of the above statements, where I’ll add a letter to help specifically reference each statement.
a). The Sprint Goal is the single objective for the Sprint. One of the Scrum values is Focus, and it is apparent when there is insufficient Focus on a Scrum Team, because it’s one of the contributing factors behind unfinished work. There are many potential causes for a lack of focus, and I won’t attempt to delve into each one of those here. Instead, I will simply say what is and is not said during a team’s Daily Scrum provides important clues as to whether a team is all on the same page about what they seek to accomplish during the Sprint.
Note: For more insights about Daily Scrums (aka Daily Standups), see:
and
b). Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. One of the aspects of Lean/Agile software development that often gets lost is how important the notion of discovery is. Especially in cases where a team is relatively new to a particular business and/or product domain, the need to allow for discovery is especially important. What discovery might look like in practice can vary considerably, from modifying one or more user stories during the course of a Sprint, to recognizing that a dependency exists that was not previously recognized, to having to significantly alter the contents of the Sprint Backlog. Regardless of which of these situations might apply, candid dialog among members of the Scrum Team (getting input from stakeholders where necessary) is absolutely critical. It is during conversations such as these that the importance of the Scrum Values of Commitment and Openness becomes especially apparent.
Note: Usage of the term “commitment” in Scrum has changed over time. For more observations about the nature of these changes, see:
c). The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. There is that word “focus” again. It’s repeated in this section on the Sprint Goal for good reason. It may be helpful here to extrapolate from what we observe in nature, where inertia causes matter to continue in a straight line (move away from the center), while centripetal force acts to move matter on a curved trajectory (toward the center). When we examine the dynamics on teams, one of the key data points is how much concurrent Work In Progress (WIP) there is. In short, the higher the WIP is on a team, the lower the output that the team is likely to achieve, which is directly reflected in its Throughput and its Cycle Time. Keeping a team “centered” is one of the primary benefits of articulating, and continuing to revisit, a Sprint Goal.
Note: For thoughts about team flow, which is closely related to aforementioned WIP, Throughput, and Cycle Time, see:
d). The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. Based on my own experience, I would say that on many teams, a draft Sprint Goal exists before Sprint Planning, and based on team dialog during Sprint Planning, it is either accepted as is, or modified based on emerging information during Sprint Planning. Regardless of how and when it plays out, it is important that the whole team is engaged with the crafting of the Sprint Goal, that the contents of the Sprint Backlog align with the Sprint Goal, and that the team understands how the work that they agree to do reinforces it. And, the Sprint Goal should be visible to the entire team (which method(s) a team chooses to use to ensure that it is visible is up to them).
Note: It’s important to understand the similarities and differences between the nature of the conversation that takes place during Sprint Planning and Backlog Refinement. For more about that, see:
e). As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal. There is a reason why “responding to change over following a plan” is articulated front and center as one of the values articulated in the Agile Manifesto. And speaking of values, the Scrum values of Respect and Courage come into play here, because sometimes it takes courage to suggest taking a different course, and having mutual respect for each other on a team is especially important when navigating the seas of change. Ultimately the conversation that the team has will dictate whether they need to significantly change course, or whether the process of discovery referenced above results in relatively minor changes to the work that needs to be done during the Sprint.
Note: The notion of having team members work together, sometimes referred to as “swarming,” can be especially important when there is a need to pivot. For more about this, see:
For a quick read on the nature of the conversation that needs to be had when encountering unplanned or blocked work, see:
How to Identify the Sprint Goal
To recap some of the previous points, the Sprint Goal helps a team focus on what they want to achieve, and helps clarify how they might best achieve that objective, based on the work that they select for the Sprint. In identifying a Sprint Goal, it can be helpful to focus on one of the following areas:
- Business or user-focused (such as delivering a new feature)
- Testing business assumptions and getting feedback
- Reducing risk (which can be done by paying down technical debt, for example).
It can also be helpful for the team to ask questions such as the following:
- Why do we need to conduct this Sprint?
- How can we attain the goal?
- How do we know when the goal has been met?
When to Write the Sprint Goal
The Parabol blog post How to Write and use a Sprint Goal provides a helpful graphic, such that it offers advice on the possible timing and sequence of events leading up to and during Sprint Planning, which is shown below:
Facilitation Tips
To sum up, many teams find it helpful to have clarity on a draft Sprint Goal early in Sprint Planning (and in many cases, a draft of it might be available before Sprint Planning). They then revisit the Sprint Goal near the end of Sprint Planning, and make any adjustments to the Goal that might be necessary, based on the information that surfaced during that conversation.
Writing the Sprint Goal
Writing SMART objectives is a familiar construct to many, and the concept can also be helpful to teams when articulating a Sprint Goal:
- Specific — be explicit about the focus of and the approach behind the Sprint Goal.
- Measurable — answer the question, “how will we know when we’ve reached the sprint Goal?”
- Attainable — determine during Sprint Planning activities whether the goal can be reached.
- Relevant — are the results of meeting this goal important? Why?
- Time-bound — what can be done by a predetermined milestone (the end of the sprint).
Sprint Goal Templates
The aforementioned blog post by Parabol mentions specific techniques for articulating Sprint Goals, each of which I’ll briefly touch on below.
- Scrum.org
- Roman Pichler
- Feature-Advantage-Benefit
- Newspaper Headline
- Tweet-length
Scrum.org Sprint Goal Template
Scrum.org‘s template looks like this:
Our focus is on <Outcome>
We believe it delivers <Impact> to <Customer>
This will be confirmed when <Event happens>
And they provide this example of how to use it:
Our focus is on sending a basic email that contains a link to a spreadsheet. We believe it delivers confidence in the product to our organisation. This will be confirmed when we have an email in an inbox.
Roman Pichler Sprint Goal Template
Roman Pichler’s Sprint Goal Template (shown below) is likely the best-known of the Sprint Goal articulation guides covered here. Roman’s template has four sections:
- Header: Document product, release and sprint this goal applies to.
- Goal: Document why it is useful to undertake the sprint.
- Method: Document how the goal will be met.
- Metrics: Document how you will know if the goal has been attained.
If we apply a similar scenario to the one that is employed in the scrum.org example, filling out Roman’s template might look something like this:
- Header: Send a basic email that contains a link to a spreadsheet, Beta Release, Sprint 12.
- Goal: Enabling the functionality of linking from an email to a spreadsheet will give us early feedback from our customer.
- Method: Deliver an email to testers and stakeholders from within our product, where we go beyond a mockup or dummy solution that doesn’t
work or scale in the actual product.) - Metrics: Email delivery success, measured by clicks coming through in our reports.
Feature-Advantage-Benefit Sprint Goal Template
Guy Maslen’s approach, of defining a feature, advantage, and benefit when writing Sprint Goals, reminds me of the mental model associated with impact mapping, and also with the basic notion behind the canonical method for writing user stories:
- Feature: The “what,” as understood from a stakeholder’s perspective
- Advantage: The “how,” articulated in terms that make sense in terms of what’s in it for the customer
- Benefit: The “why,” ideally articulated as an outcome
If we were to once again write a Sprint Goal using the email example, using Guy’s template, it might look something like this:
- Feature: Send in-product email that includes a link to a spreadsheet
- Advantage: Enable testers, stakeholders, and customers to provide actionable product feedback on the spot
- Benefit: Get early visibility into product improvements that our customers want
Note: For more about impact mapping, see:
Newspaper Headline Sprint Goal Template
The notion of writing in a way that resembles a newspaper headline is an idea that makes sense in many contexts, and Sprint Goals certainly qualify. I would also add that some teams might even inject an element of fun into the wording they choose to use, while at the same time making it clear what they seek to accomplish. Once again returning to our email example, a team might a Sprint Goal something like this:
- Team Rarified Air Releases Embedded Email Feature
Enabling Immediate Insight into Product Improvements
Tweet-length Sprint Goal Template
I suppose it should go without saying that Sprint Goals should be short and easy to understand. The way I would suggest applying this “template” is to use a particular character or word limit as a sanity check when writing Sprint Goals.
Conclusion
Sprint Goals are prominent in the Scrum Guide for a reason, because they help a team stay in alignment on what they wish to achieve during a Sprint. One more closing piece of advice that I will offer is one that teams I’ve worked with have heard me say often — Voltaire’s maxim “Don’t let the perfect be the enemy of the good.” That is to say, by all means be thoughtful when articulating Sprint Goals, but don’t let it become an end in itself; it needs to be just good enough to achieve its intended purpose of providing clarity and setting expectations, both to the team members and to stakeholders, on the outcome they intend to accomplish as of the end of the Sprint.
