Reviewing 4 Different Sprint Goal Templates
Coming Up Next: My Own Sprint Goal Miro Template
I’m currently creating a Sprint Goal template in Miro, which will be released soon. I thought it would be interesting to compare some of the different templates available to determine their comparative strengths and weaknesses.
I’d ultimately like to position my template to provide something unique and valuable, but I would consider it a waste not to share this byproduct of my Sprint Goal template creation journey with my readers.
I want to stress that it’s super easy to pick things apart. Any template will have its pros, cons, strengths, and weaknesses. The goal isn’t to criticize the work of others or bring their templates down but to show you in what cases these templates might be the best fit for your situation.
That being said, one template contained so many mistakes and misconceptions while not being vastly different than another template that’s already out there, that I do not recommend using it at all.
You can’t be the best at everything, and there isn’t one size fits all best template out there. What’s best depends on your situation.
With these caveats in mind, let’s start by examining Steve Trapps' Sprint Goal template.
1. Steve Trapps’ Sprint Goal Template
What I really like about his template is the simplicity. It’s easy to fill in, which means you can get started immediately.
However, the template lacks definitions for what you must provide. What’s an outcome? What’s an impact? The difference may be obvious for experienced practitioners, but it isn’t clear for everyone who will find the template and try to use it.
Luckily, Steve does provide clear examples that we can use to reverse-engineer the intended meaning:
“Our focus is to have a tidy garage that we can put our car in
We believe it decreases the risk of the car being stolen and increases our peace of mind
This will be confirmed when the car is in the garage and out of sight.”
<Outcome>: what we’re trying to achieve with what we do.
<Impact>: the impact we will make when we achieve what we intend to achieve.
<Event happens>: how will we know we achieved our outcome?
Something to note: The customer seems to be omitted from the examples provided (probably because they are obvious in the examples), and most Scrum Teams are not in the business of cleaning garages. I suspect Steve chose to prioritize examples that people can more easily relate to, no matter their line of work, rather than being clearer for Scrum Teams in an IT context.
Ideally, <Event happens> should cover both the Impact and the Outcome. Our garage may be squeaky clean, but what if the risk of the car being stolen actually increases because the garage now looks nicer and more attractive for stealing the car? Or we actually become more stressed, which is the opposite of having peace of mind because we’re busy polishing it every day.
The outcomes may not result in the desired impact, so you need more than <Event happens> to inspect the outcome. The template also doesn’t discuss the Output we’re producing to achieve a certain outcome.
Pro’s:
Easy to use
Concrete and clear examples
Con’s:
What are we confirming, the outcome or the impact? The outcome may produce the impact we aim for, or it might not. Ideally, the section <Event happens> should cover both.
Outputs drive Outcomes. Where are the Outputs we’re producing to achieve said Outcome?
Unclear how you would embed this template in Sprint Planning.
2. Roman Pichler’s Sprint Goal Template
This is probably the most popular Sprint Goal template. It’s easy to fill in, and it emphasizes how we can validate whether we’ve achieved our objective. Itis biggest downside, which could easily be fixed, is that it contains no concrete examples. The template seems more geared toward teams that are strong in discovery and validation, which I don’t think (sadly) are most Scrum Teams out there.
The template covers the following:
GOAL - What are we trying to achieve? It doesn’t have to be delivering a feature. It could also be testing an assumption.
METHOD - What technique will we apply to discover whether we’ve achieved our goal or not? What validation technique will we use?
METRICS - How will we measure whether the goal has been met? What are the success criteria we’ll use?
Pro’s:
Easy to use
The template covers different situations, such as teams focused on delivering features or focusing more on discovery and testing hypotheses.
Splits out the goal, method, and metrics so that we think about all three separately.
Con’s:
No concrete filled in example is provided in the template, it does contain some pointers.
Unclear how you would embed this template in Sprint Planning.
3. Scrum Facilitator’s Sprint Planning Template
Disclosure: I sometimes work with the Scrum Facilitators, and Erik de Bos was one of the reviewers of my book. However, I hope you will trust this will not influence my judgment.
This template takes a fundamentally different perspective than the other two templates we’ve examined: how do we consider setting a Sprint Goal within the context of the Sprint Planning event?
Pro’s:
Crafting a Sprint Goal can be easily integrated within your Sprint Planning.
Explicitly asks the team to state what makes the Sprint valuable, which may mean things can be included that are not easy to measure but do matter, and also any relevant context that matters.
The template is designed to make crafting the Sprint Goal a collaborative team effort. This ensures common understanding and ensures you will be getting the most value out of Sprint Goals.
Con’s:
No concrete examples are provided in the template.
Doesn’t split out Metrics and Method for measuring whether we’ve achieved our result.
4. Sprint Goal Planning Template - Amsterdam University of Applied Science
To be frank, this is the worst template of the lot because it was created by people who seem to lack a deep understanding of what they’re doing. This is pretty sad, especially since it’s provided by the Amsterdam University of Applied Sciences.
The template seems heavily inspired by the template of Roman Pichler, but they made it worse. They would be far better off using the original template.
The misunderstandings present in the template:
Tasks and sub-goals are conflated. If you have a goal, and you’re going to make sub-goals into tasks, then don’t call them sub-goals but tasks.
The Definition of Done is abused. Acceptance Criteria are not the same as a Definition of Done.
Populate your Kanban board. Scrum doesn’t mandate using a kanban board.
I’m not listing any pros and cons, as I’d suggest skipping this one completely. If you like the general concept of the template, I’d simply go for the Roman Pichler’s template, which is basically a superior version minus the misconceptions.
What’s Still Missing After Reviewing These Templates?
I want to stress that whenever you create a template, you must make choices that come with advantages and disadvantages. Slippers are great for the summer, but they suck for the winter. Whether a template works better than another one also depends on the context you’re operating in.
Some topics weren’t tackled in any of these templates, which I believe could add value.
When I wrote my book on Sprint Goals, the number one question I received was: How can you write a whole book on Sprint Goals? They would then state that Sprint Goals feel redundant as they repeat something we already know.
When I give talks about Sprint Goals, I most often get questions about why they are unable to make Sprint Goals work in their situation. And often when I ask some more questions, it makes perfect sense why they are unable to benefit from Sprint Goals.
I also believe providing the relevant context of a Sprint Goal is crucial. An objective does not exist in a vacuum, there’s a reason the Sprint Goal is relevant, and I believe it’s crucial to provide that context - the why, as that will result in a much deeper understanding that can be used to make better decisions than simply just providing an objective.
Even if they begin working with a good Sprint Goal, there are many anti-patterns to watch out for. That’s why I think it will also be useful to include a list of common anti-patterns.
For this reason, I intend to include five things when I create my Miro Sprint Goal template:
Why do Sprint Goals matter? This ensures that everybody is on the same page about their value, and not simply does them because they are required by Scrum.
Are we ready to begin working with Sprint Goals? I will include a Sprint Goal Health check with some questions you should be asking yourself, before deciding to work with Sprint Goals. Sprint Goals are incredibly hard to do well.
Not just what we’re trying to achieve, but the relevant context - the why, so that we know why what we’re trying to achieve matters.
Common Sprint Goal anti-patterns. What traps may lure us away from getting the most value out of the Sprint Goals?
Make the template collaborative. By leveraging the collaboration superpowers of Miro, we can create a template that makes formulating a Sprint Goal a collaborative effort by all the team members in the Scrum Team.
When I include these different elements, I believe I will provide something different from what’s already available.
Until then, please consider trying out these templates and see whether they make your life easier.
I have had very good success in using the Scrum Facilitators template for exactly the reasons you state.
Hi Maarten,
Here's a format I recently used with Product Owner and a Scrum team - the origin escapes me.
Slide 1: what we thought would happen (our goal)
Slide 2: what actually happened (here's where we show our work)
Slide 3: what we need from you (our biggest questions eg have you had an opportunity to use the app)
Slide 4: what's next (our guess as to the goal)
Why we liked it as a team: it helped communicate our uncertainty to our sponsors and customers attending our reviews. Became easier over time to talk about things going wrong, constraints and get attendees to participate. We got good attendance and in some reviews convinced customers to demonstrate what they liked and did not like about the finished reporting apps. On one occasion the presenter was the sponsor who asked for the work to be done.
The context: a business intelligence team building reporting apps in a government transport agency. One of the challenges they identified when I started was getting stakeholders to care, and show up.
How the story ended:
I am sharing it here because as soon as the project was complete all this team momentum was lost. The team was dispersed to other work. The product owner's contract finished and she left. I am hoping one day the idea of long standing teams sticks. But I cannot see it happening with the current funding model and leadership. This is because of the short term project mindset, and approach to organizing everyone into resource pools. People are thrown at projects typically and then pulled out of them at short notice. The word "delivery" is frequently used, and "value" - rarely.
One thing will endure from the experience: Interviewed by volunteers from outside the project the team involved were enthusiastic about their work and the bonds they made working together. So were the stakeholders. I'll remember this as something I was proud to be part of too.