Today I scheduled another one of my three-weekly company talks on Scrum. This time I prepared a presentation for my peers on the topic of the benefit of using (great) Sprint Goals. I have rewritten the structure and contents for publication on this blog.
In brief: a Sprint Goal is the single objective that defines the purpose of the Sprint. It outlines a business objective or a feature of a product.
Using a Sprint Goal creates transparency and is a negotiation-tool between Product Owner and Developers to determine the scope during the Sprint. With a Sprint Goal, the expectations between the Product Owner and the Developers are clear.
The Sprint Goal can also be seen as the ultimate elevator pitch of the Sprint. Imagine striking up a conversation with a stakeholder at the coffee machine, who says, “I’m looking forward to the Sprint Review next week! What am I going to see?” So, how do you react? Are you going to sum up a list of PBIs? If you struggle to give a short and concise answer, it seems that there is little cohesion in the Sprint. A Sprint Goal helps in that regard!
The ‘forgotten man’ of Scrum
Though using Sprint Goals has great benefits, they are often regarded as the forgotten man (or the neglected child, or poor relation – you see where I am getting at) of Scrum. Not using a Sprint Goal puts the Scrum teams at risk of applying Scrum in a mechanical way.
Without a Sprint Goal, as a Developer, you’re basically like a lumberjack. You hack and saw your way through PBIs without really understanding why you do what you do. Sprints become ‘hamster wheels’, with functionality and people moving ‘through the works’. There is no purpose other than ‘finishing the job’. What this looks like in practice:
- Transferring work between sprints becomes the norm. “We’ll finish that story in the next sprint, right…?”
- A Sprint Goal is used (hurrah!), but it’s nothing more than “finish all the user stories” (boo!)
- The quality suffers. If you don’t know why you’re doing something or who it’s for: do you care about the quality?
In my experience, the most effective, happy and successful Scrum Teams make good use of Sprint Goals. Using a Sprint Goal leverages the power of purpose: a powerful tool that brings teams together, keeps them inspired and motivated to achieve great things! In this blog post I will talk about what the use of a Sprint Goal entails. How it enhances work, manages expectations in the Scrum Team (and beyond) and can have a positive effect on personal and team motivation.
What does the use of a Sprint Goal look like in practice?
Sprint Planning
The conception of the Sprint Goal takes place at the start of the Sprint, at the Sprint Planning. The purpose of the Sprint Planning is to give focus and purpose to the Sprint – and setting a Sprint Goal is essential.
In the Sprint Planning, a realistic and coherent amount of work will be planned that is projected to be finished at the end of the Sprint, where issues are moved from the Product Backlog to the Sprint Backlog. A Sprint Goal can be a useful guideline, as it sets a certain prioritization: which PBIs do attribute the most to the Sprint Goal?
The Product Owner, knowing the product and the priorities best, should already have a Sprint Goal in their mind in advance. However, this Goal is still open to negotiation with the Developers – they might add useful insights due to their experience, skills and capacity.
Starting with a predetermined Sprint Goal can be seen as a more top-down approach. Another approach is gathering and selecting a coherent and related group of PBIs; a bottom-up approach.
In general, PBIs are selected from the top of the Product Backlog, the ones with the most priority. But it might be good not to stare yourself blind at the order of the Product Backlog. It can be sensible to select PBIs with some matter of coherence, issues that together deliver more value to the end-user. The more cohesion, the better!
This is important: the Scrum Team commits to the Sprint Goal.
Which does not (and I repeat: does not) imply that you should commit to getting “all the PBIs to a Done status”. The Scrum Team should keep each other accountable to achieving the Sprint Goal. The actual work (as in the scope within the Sprint) is flexible. The Sprint Goal, just like the timebox of the Sprint, should be seen as universal truth.
This does not mean that you cannot have any PBIs in your Sprint that are unrelated to the Sprint Goal! It is an utopia that all PBI’s should be related to the Sprint Goal. For instance, when you include PBI’s related to resolving technical debt. However, not Sprint Goal-related PBI’s should be outnumbered, as those would likely be the first PBI’s to be dropped if reaching the Sprint Goal is in peril.
The Daily Scrum (and during the Sprint)
During Daily Scrum, a lot of focus is usually put on answering the three questions (what have I done yesterday, what am I going to do today and are there any (potential) troubles?). You could also rephrase these three questions to revolve around the Sprint Goal:
- What have I done yesterday that contributed to achieving the Sprint Goal?
- What am I going to do today to contribute to achieving the Sprint Goal?
- Are there any challenges we face in achieving the Sprint Goal – and how can the Scrum Team help?
A clear goal ensures optimal self-organization and cooperation and frequent reflection on a Sprint Goal helps a lot. I usually compare the use of a Sprint Goal during Daily Scrum and the Sprint as navigating a Spanish galleon on a long sea journey towards a faraway harbor. Every once in a while you need to correct your steering course, keeping in mind weather conditions, wind (and pirates, obviously).
A Sprint Goal reduces complexity, provides focus and reduces waste as it gives a good view on what matters most, right now. As time progresses and more knowledge is attained, you might run into new insights that might jeopardize the Sprint Goal. And you can adapt accordingly: changing the scope by amending the way the Scrum Team approaches certain PBIs, or even kick work of a lower priority out of the Sprint. That’s allowed! Remember, we committed to the Sprint Goal, not on finishing specific PBIs.
Sprint Review
The Sprint Review is an event to inspect the new increment with the Scrum Team and the stakeholders. A great opportunity to look back – and forward!
The Sprint Review is often regarded as a ‘demo’, where the Developers walk through the delivered features. Though this gives a lot of focus on individual PBIs. Wouldn’t it be way more interesting to reflect on the Sprint Goal as well? It gives all participants a tangible goal to reflect upon: why did we do what we do again? What is the impact we are trying to make?
I would recommend using the Sprint Review to also reflect on the Sprint Goal. How does this relate to the product vision? And was the Scrum Team successful in achieving the Sprint Goal?
Working with Sprint Goals upgrades a ‘demo’ to a full-fledged Review. And might even motivate your stakeholders to actually show up!
Sprint Retrospective
The Sprint Retrospective can be used to reflect on the processes during the Sprint. A few question that can be raised are:
- How can we craft a better Sprint Goal?
- Did we feel motivated in achieving the Sprint Goal?
- What were the troubles that plagued our team that impeded us in reaching our Sprint Goal?
And how can we prevent/solve them?
Sprint Goals and overarching goals and visions
A Sprint Goal usually does not stand on its own. It is usually (or should be) part of a grander plan or vision. Think of the subsequent Sprint Goals as a chain of objectives that lead to an overarching product vision, and might even help to achieve the company vision.
Goals and plans for the day-to-day proceedings and the Sprint are the domain of the Scrum Team, but defining the overarching product vision, product strategy and release plan are the domain of the Product Owner. Even overarching those are the company vision and the business strategy, which are the domains of the executive team. You could perceive the scaling from the company level to the day-to-day level as an onion, peeling towards a more detailed level. It is important that all visions and goals align.
The impact of Sprint Goals on ‘drive’
One of my favorite books is ‘Drive’ by Daniel H. Pink. This book was gifted to me in 2012, and I have been reading it off and on since then. This amazing book that gives insights in what drives and motivates people. Dan makes a case for focusing on intrinsic motivation instead of extrinsic motivation. Extrinsic motivation is motivating people through external flunkies, like bonuses – the typical stick and carrot motivation – do well and you’ll get a reward, but do badly and you’ll be punished.
Instead Dan Pink focuses on the power of intrinsic motivation, a motivation that comes from inside a person. Intrinsic motivation is stimulated through three factors:
- Autonomy is the desire to be self-managing and to have control over how you perform your work;
- Mastery is the desire to get better at what you are doing;
- Purpose is the knowledge that what you are doing is for a reason, that it contributes to something worthwhile and greater than just the task itself.
Using Sprint Goals is to cater to purpose – and in effect to intrinsic motivation. Without a shared goal, it’s easier for the team to follow divergent paths and to lose purpose and cohesion.
So, what makes a great Sprint Goal?
There is no clear cut formula on how to write up a Sprint Goal. Some might opt for a very thorough approach, using SMART to set up goals. Though that might help, these kind of methodologies might also feel very restrictive. No matter what the form, the focus should be on the content of the actual Sprint Goal itself. It is good to keep three principles in mind: focus, flexibility and purpose.
A great Sprint Goal…
- gives enough focus so that at the end of the Sprint there is working valuable Product Increment;
- has enough flexibility that the Team can adjust their plan (the Sprint Backlog);
- gives a sense of purpose so that the Scrum Team sees the value and meaning of their work.
Some clear handles that might help:
- Avoid compound Sprint Goals. For example: “Build X, Y and Z”. What is the most important of these goals?
- Don’t try to micro-manage with Sprint Goals. Using a Sprint Goal such as “Complete all the PBIs” is basically not having a Sprint Goal at all;
- Try to make the Sprint Goals measurable. When are we successful?
- Don’t skip on reaching consensus within the Scrum Team on the formulation of Sprint Goal. It has to be carried by everyone!
- Try to create Sprint Goals that make an impact on the experience of the end-user. Are you solving a big problem? Let it be known!
- The Sprint Goal should be not interchangeable with other Sprints: the Sprint Goal of every Sprint should be unique.
As a format, I recently came across an article on Scrum.org called “Sprint Goal Template” by Steve Trapps. In this article, Steve proposes a specific format:
Our focus is on {outcome}
We believe it delivers {impact} to {customer}
This will be confirmed when {event happens}
An example of this filled in would be :
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 organization
This will be confirmed when we have an email in an inbox
(Though I would prefer having a Sprint Goal of one sentence like “Sending a basic email in an inbox that contains a link to a spreadsheet, to deliver confidence in the product to our organization”… but you get the idea.)
Using clear objectives: a growth model
In the book “Scrum Mastery”, the author Geoff Watts illustrates growth models to assess the maturity level of the team on different aspects. With regards to using clear objectives, Geoff illustrates the following levels:
- Level 1: Delivering work with ad-hoc priorities;
- Level 2: A prioritized backlog without using Sprint Goals;
- Level 3: A prioritized backlog with Sprint Goals;
- Level 4: The Sprint Goal is part of a ‘release goal’ with clear customer representation;
- Level 5: Sprint (and release) Goals are mapped to strategic objectives with clear ROI justification.
Using a maturity level might be a good way to assess the level of agility within your organization and give good handles to strive for improvement.
Closing
Adopting Sprint Goals takes time. Luckily the nature of Scrum is working in Sprints in which you can apply, learn and improve. Crafting a good Sprint Goal is an art, a skill which you can hone only by actively doing and improving it. If you use it within Sprints, you can give it a larger and larger role. Aligning the Sprint Goal with overarching goals, reaching up to the product vision and the corporate level can give more meaning to the work that you do as a Scrum Team. Having a good Product Owner and involved C-level management on board might help in that regard!
But the most important outcome of using Sprint Goals is working on the intrinsic motivation of the Scrum Team. Which makes teams happy and efficient!
Reading list
- “The Professional Product Owner” by Don McGreal & Ralph Jocham
- “Mastering Professional Scrum” by Stephanie Ockerman & Simon Reindl
- “Drive” by Daniel Pink
- “Fixing Your Scrum” by Ryan Ripley & Todd Miller
- “Scrum Mastery” by Geoff Watts