The youth of today are always talking about squad goals - aspirational attainments for a group. It’s a nice concept and actually built into the Scrum framework, as Sprint Goals.

I’m personally a big advocate of having a Sprint Goal, but they seem to be the least-adopted of all the named things within the Scrum Guide. Without one, you have an implicit goal: “do all the stuff in the sprint”. That’s boring! It doesn’t motivate, inspire or help us understand the value in what we’re doing. Let’s do better than this!

What’s the Value?

A Sprint Goal provides the team with a shared focus - a method to concentrate our efforts. A good goal clarifies the understanding of why we’re doing the work. It gives the team the tools to prioritise the what and inspires them to devise the how. It’s a motivational tool that unites us as a team.

The Scrum Guide itself has the following to say on the goal:

The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Note that the Sprint Goal is a singular, named term. There is one per Sprint, agreed upon by the team during Sprint Planning. This provides the shared vision and forms the commitment. As you’re putting backlog items into the Sprint, you’re doing so with a common purpose - does this help us meet the goal? Once everyone’s happy that the work is doable (to their understanding) and are aligned that this will help achieve the goal, the Sprint can start.

Your Sprint Goal therefore describes the priority of your team. Note that priority is also a singular term. Don’t believe me? Here’s some useful links to persuade you!

Still not convinced? Tell me what your priorities are (note: plural) when the fire alarm sounds. You’re not going to instruct one person to stay behind to work on the “secondmost priority”. But we try and doublespeak this away with the notion of a “top priority”. A Sprint Goal can overcome this misuse of the term, aiding the prioritisation effort in a binary way - something’s in the Sprint, or it isn’t. During your daily standups you inspect your progress towards the Sprint Goal, adapting as necessary.

(Pragmatism point of order - there’ll always be stuff going into a Sprint, like bugs and minor style points, that aren’t perfectly aligned with the goal. That’s life.)

Reporting is much easier too - rather than taking “the sprint board” to the stakeholders, or even worse, transcribing it into Excel and changing stuff (please don’t) - you can communicate the goal itself. This is why I find it useful to keep the Sprint Goal at the elevator pitch level. Not only does it keep you out of the detail, but it clearly sets out what it is the team wants to achieve in a simple way.

Setting Your Goal

Now to the difficult part, actually setting a goal.

Don’t get too distracted by attempts to find the exact magic incantation - I’ve witnessed teams say “keep it in a tweet” (back in the 140 character limit days), or stick to a sentence. I personally like the linguistical challenge of the latter, but that’s not the purpose of the exercise.

Be cautious about the word “and” in a goal - that implies a split focus, or that you’re possibly re-stating the sprint items. Note the difference between a task and a goal. My wife informs me that there’s a useful concept at play in the education sector to help explain the difference. Within a lesson (read: Sprint) you have a series of success criteria, which seek to achieve the overall learning objective. The success criteria, like our sprint’s tasks, are the stepping stones to achieving the goal. If the items in the Sprint amount to building a lunar lander, then the Sprint Goal would be to land on the moon.

I was curious about the choice of the word “Sprint” within the Scrum Guide. Superficially, “iteration” seems like a more descriptive fit. It’s partially to communicate that the timebox is short in length, typically less than a month. Moreover, it’s suggesting a motivation to rapidly do something. What is that something? The purpose of an iteration isn’t just to deliver some features. Whatever’s on your roadmap is of unknown utility until it’s out there in the wild. An iteration, therefore, is a dash towards challenging assumptions, reducing the risk, gathering data from your experimentation and increasing our understanding. As per the Agile Manifesto, we want to:

satisfy the customer through early and continuous delivery of valuable software

and be flexible to:

welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

so that we can agree that:

working software is the primary measure of progress

In a rapidly-changing competitive marketplace, you need to get your ideas out there and start learning from them. Ideally, make some money too! Orient your goals in that way - what problems are you trying to solve for your users? What uncertainty are you wanting to address? That’s why we sprint towards a goal!

Goals framed in this manner are so potent because of the avenues for creativity they open. The desire to answer the question, to learn the unknown is tantalising. What a way to motivate your team!

You will also need to specify how you’ll know when the goal is achieved. It’s not necessarily when all the tickets are in the DONE column. All good hypotheses have a quantifiable aspect. Very often this aligns with key business metrics, which then helps you further understand how your product is used by the end users, so you can perform future iterations!

Shoot and Score

Overall, Sprint Goals help you avoid the trap of doing waterfall within an agile-like framework. Without a clear goal your Sprint is simply a bucket of work. The items in Sprint will have confused priorisation. it will seem like there’s progress on lots of different things, but no progress overall on the higher-level outcomes. Instead, work intensely to achieve the one goal. See how that changes things and how happier it will make your team members.