Properly implemented sprint goals can help you propel the team to a new level. Although they are one of the most important aspects of scrum itself, they are sadly also one of the most neglected.
Let’s revisit what a sprint goal is, its purpose, and how to use sprint goals..
Table of contents
What is a sprint goal?
In simple terms, a sprint goal briefly explains what the team sets to achieve during a sprint. It isn’t necessarily a strict estimate but a committed declaration of intent.
By principle, achieving a sprint goal is a big step toward your overarching product goal:
To put it into context, here are some examples of sprint goals:
- Build capability to list products
- Create a basic website structure
- Launch the website
Why do developers need a sprint goal?
Why even bother with framing sprint goals? Isn’t just pulling tickets from the product backlog to the sprint backlog enough?
Although selecting tickets for the next sprint constitutes a vast majority of sprint planning, there are a few ways framing specific sprint goals brings value to the team. Framing sprint goals:
Keeps the team focused
A lot can happen within 1–2 weeks of sprint time, such as ad hoc bugs, priority changes, among many others. It’s not uncommon to plan a few key items during sprint planning just to realize after a few days that you are working on entirely different tasks.
In such cases, a sprint goal helps keep the team grounded in what’s truly important. Whenever a new request or ticket appears, the team can assess whether it contributes to their sprint goal and prioritize accordingly.
That does not happen with a mere list of sprint backlog items.
Enables self-organization
Self-organization is a beautiful, albeit challenging, concept. You can’t just tell the team to“self-organize and expect the magic to happen.
Self-organization requires two critical elements:
- A clear objective
- A set of clear boundaries defining the scope of the team’s self-organization and what’s established by the company, stakeholders, etc.
Sprint goals answer the need for a shared objective. With a robust goal in mind, a team can start self-organizing on how they work, how they remove blockers, and how they maximize chances to achieve the goal. It gives a unified sense of purpose towards which the team can self-organize.
Learn more →It’s easier to self-organize towards a particular North Star than toward 20 micro-objectives such as sprint tasks. It also gives the team more breathing room to define a path forward rather than just moving tickets on the board.
Manages expectations
Sprint goals give a clear answer to what everyone should expect from the team by the end of the sprint. Stakeholders and other teams don’t have to ask for that nor go through the sprint backlog to figure out what the team will deliver. They also answer what’s NOT on the team’s must-have list for the upcoming sprint.
This is especially important as the company grows. Being able to review multiple teams’ sprint goals can quickly give a high-level view of where a given department is heading and where there might be potential issues along the way.
How to use sprint goals well
There are many challenges associated with properly implementing sprint goals. However, there are tactics that’ll help you avoid most of the obstacles.
Here are four tips I have for everyone implementing sprint goals:
- Hold the team accountable for sprint goals
- Aim for 70–80 percent of capacity
- Frame them to fit the team’s context
- Clearly define “done”
1. Hold the team accountable for sprint goals
The biggest waste that can happen is spending time to frame sprint goals just to ignore them altogether.
You must build a culture where sprint goals are at the center of the team’s attention. If you just declare a sprint goal on the planning and then wait two weeks to review it (or, worse, forget it altogether), you won’t reap any of the sprint goal’s benefits.
Tactics to make the product team feel the ownership over sprint goals include:
Proper dailies
A daily meeting shouldn’t be a status meeting. Rather than asking everyone what they are working on, ensure the team answers the question, “Are we on track with the sprint goal?” It’ll frame their thinking and spark the right conversations.
Proper retrospectives
If you don’t achieve a sprint goal (90-percent completion is still a non-achieved goal), make it a big topic of the retrospective. Discuss the reasons, look for improvement, and decide the next steps.
If needed, do it on every retrospective. The goal is to show the team that not hitting sprint goals is actually a big deal. If you let unmet goals slip, you won’t ever build accountability toward them within the team.
Celebrate success
It’s also important to show the team that meeting sprint goals is also a big deal. Make sure the team feels product and appreciates when they achieve the sprint goal.
2. Aim for 70–80 percent of capacity
I don’t believe in overly ambitious sprint goals.
If you work in an environment where you have full focus and can avoid all interruptions during the sprint, feel free to plan your whole capacity around your sprint goal. But, let’s be honest, most of us don’t have this comfort.
Things usually happen during the sprint. Let’s just accept it as a fact of life. The best approach, from my perspective, is to frame sprint goals in a way that takes roughly 70–80 percent of the team’s capacity. That leaves 20–30 percent for minor work, technical debt, distractions, and ad hoc requests.
I’d rather have five smaller sprint goals fully delivered than five overly ambitious goals that are 80-percent done.
3. Frame them to fit the team’s context
There are various ways to frame a sprint goal. The most common one is to deliver user value with every sprint. That makes sense on paper, but it’s not that easy to achieve.
Don’t get me wrong; I don’t mean to discourage you from taking the “proper approach.” Just don’t get too fixated on that. If the current context on your team requires you to work on more technical issues (e.g., refactors), then feel free to frame the goals in a way that makes sense for your scenario.
Once again, I’d rather have imperfect but achievable sprint goals than properly framed goals we’ll never meet. Context over theory.
4. Clearly define ‘done’
Lastly, make sure you have a strong definition of what “done” means.
If you focus too much on achieving sprint goals without first establishing a healthy definition of done, you’ll have a lot of challenges determining whether the sprint is completed or not. It’ll just bring needless discussion and chaos.
The definition of done is essential for the proper implementation of sprint goals.
Summary
Sprint goals are an essential element of the product development lifecycle and one of the most critical elements of the scrum framework.
They help establish the right rhythm, help the team focus, enable self-organization, and frame expectations across organizations.
Yet, properly implementing sprint goals is a bit more nuanced than just putting them next to your sprint board. Getting the full benefits of sprint goals requires some thought and effort.
To summarize some best practices for establishing and using sprint goals:
- Build dailies and retrospectives around sprint goals
- Celebrate success
- Aim for 70–80 percent team capacity
- Frame goals to fit the current team context
- Make sure a robust definition of done is in place
Sprint goals are one of those concepts that’s easy to understand, yet difficult to master. Rest assured, the benefits they bring are worth the effort.
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
