You could say that the basic unit of the Scrum framework is the sprint – a defined period of time in which the Scrum team undertakes to achieve specific progress toward the overall product goal. But how can you ensure the necessary level of focus? That’s what the sprint goal is for. Read on to find out what sprint goals are, how they benefit the Scrum process, and some top tips for setting tightly-focused goals that will make your sprint a success.
Table of contents
What is a sprint goal? – a definition
If you check out sprints at scrum.org, literally in the middle of the page is the statement, “During the sprint: No changes are made that would endanger the sprint goal.” From this, it’s clear that sprint goals are important (arguably, there’s nothing more important during a sprint) so what exactly are they?
“A sprint goal… is a short statement that defines the objective of the sprint.
A sprint goal… is specific and measurable (like all good objectives).
A sprint goal… tells you what the team is committed to deliver.
A sprint goal… tells the team (including the product owner) exactly which parts of the product backlog will be worked on (and achieved!) during the sprint period.”
A sprint usually focuses on either producing new features, addressing risks (e.g. fixing an issue with the product or design), or testing product assumptions. To quote scrum.org one more time, an effective sprint goal:
- Serves to test assumptions, address risks or deliver features.
- Ensures a focused daily Scrum meetings.
- Provides guidance to the development team on why it is building the product increment.
- Helps setting priorities when “the going gets tough”.
- Fosters teamwork and team building by jointly working towards a shared sprint goal.
- Supports the product owner in creating the product roadmap.
- Stimulates product backlog cohesion when planning a release.
- Can be used as an instrument for stakeholder management.
- Supports focused sprint planning.
- Enables efficient decision-making.
Sprint goal example
Sprint goal ensures that everyone is striving in the same direction, with a common understanding of the product increment the team is working to create. What does it mean in practice? For a digital product that requires users to log in before using it, an example of a sprint goal could be something like this:
Feature goal: User is able to log in to our application.
Risk goal: Product architecture is designed to support the necessary level of performance.
Assumption goal: User is validated in terms of willingness to register prior to using the product
Why are sprint goals necessary? What are the benefits?
Hopefully, the need for clarity on what the team is developing is something we can all accept. However, to get a little more specific, the benefits of agreeing to a sprint goal also include:
- Each sprint goal is a step in the journey to the final or released product – taken together, the project’s sprint goals lay out the product roadmap, telling the story of the product’s development.
- The development team have a focus for discussions about progress and priorities.
- Decision-making is easier with sprints goals – whatever the issue, the key question is: Does it bring us closer to achieving the sprint goal?
- The sprint goal drives the team to deliver the next product increment – the goal acts as motivation.
- The sprint goal is the heart of the sprint planning process, giving it a focal point.
- Sprint goals also provide clarity to investors and other stakeholders with an interest in the product.
Sprint goal best practices
So, how can you agree on sprint goals that will be achievable, motivate the development team, and satisfy the product owner and stakeholders? Let’s start with three key questions offered by ‘Scrum guru’ Roman Pichler:
Why do we carry out the sprint? Why is it worthwhile to run a sprint? What should be achieved?
How do we reach its goal? Which artefact, validation technique, and test group are used?
How do we know the goal has been met? What is your success criterion or ‘definition of done’ for the sprint goal?
As we can see, creating a solid sprint goal needs a foundation of understanding – you need to know not only what you are aiming to achieve but also why. It helps to think of your sprint goal in terms of the benefit you are trying to create with the product increment.
What are you not sure about?
Another tip from Pichler is to consider the current uncertainty in the project. Early on in the process, it is often helpful to focus sprint goals on the product risks and assumptions – those things you need clarity on before really starting to design and build. Later, the focus can be shifted to features and UX design.
Ask yourself, what is critical?
When sprint planning, your sprint goal should be driven by priorities. What is it that needs to be addressed immediately? What is it that, if not addressed, could end in disaster (or at least, a product increment that does not bring you closer to meeting business and user needs)?
Think about measurement
Going back to Pichler’s third question, how will you know when the sprint goal has been delivered? Think about which metrics will give you that information. The right metric will depend on what it is you are aiming to achieve – is it ease of use and accessibility, or a clearer picture of user needs or pain points, or is it a practical test of functionality? Whatever metric you go with should give you the data and information to know whether the sprint was a success.
Failure is part of the process
Yes, sprint goals should be achievable (and ideally, achieved) but there are always unexpected factors or changes in priority or direction. Sometimes what seemed reasonable at the planning stage just cannot be done. Such ‘failures’ are valuable sources of information and should feed back into the planning cycle (the kind of thing you discuss in sprint retrospective meetings) and influence future sprint goals.
Potential sprint goal pitfalls
Sprint goals bring their own challenges. Here are four of the most common, and what you can do about them:
- The sprint goal is too ambitious – You’ve set a sprint goal that tries to achieve too much and set the team up for failure; this can reduce the team’s overall velocity. Next time, consider the resources and time you have available in more depth; maybe add resources or talent to the development team if deadlines are tight and non-negotiable.
- The sprint goal is too ambiguous – Everyone involved needs to understand precisely what the sprint goal is asking them to deliver. The key to avoiding vague sprint goals is to ask the question, How will we know when it’s done?
- The spring goal lacks relevance – The goal is not focused on the business or users, and the team cannot see how it contributes to the overall product vision. Always ask, What impact will this sprint have on the business? and, How will this sprint affect the user.
- The team loses focus during the sprint – Everyone works on their own responsibilities, losing sight of the overall sprint goal. It’s important that everyone understands their work in the wider context. Make your sprint goal visible – put it on the wall (real or virtual). Talk about it in daily Scrum meetings.
Sprint goals for success
The sprint goal is a critical tool for good performance during the sprint. It should keep the whole team focused and on the same page, working towards the same overall objective. Ideally, this means discussion and the involvement of the whole team in the sprint planning process, leading to a precise and agreed sprint goal. The sprint goal is used to drive progress and reduce uncertainty, leading to a product increment that is a definite – and useful – step on the road to delivering the product vision.
Share this article:
