Scrum from the Trenches - The Sprint Goal

(Netherlands)

April 6, 2018

Time to read: 8 minutes

In the "Scrum from the trenches" blog post series I like to address topics that I encounter in practicing Scrum in the real world, with real Scrum Teams. Sharing where theory comes into practice, what challenges teams encounter along the way and ways to help Scrum practitioners use the power of empiricism to overcome these challenges.

The Sprint Goal

We'll start out this series with addressing common challenges regarding the Sprint Goal. Let's first briefly introduce the Sprint Goal as a concept in Scrum.

A goal is mentioned many times in the Scrum guide in different contexts. The most recent version of the Scrum Guide (2020) talks about the Product Goal as a commitment to the Product Backlog and the Sprint Goal as being the commitment for the Sprint Backlog. Having a Sprint Goal is of great importance for achieving your overall business objectives and customer satisfaction. And if gives purpose to the current Sprint.

The Sprint Goal is crafted during the Sprint Planning and fosters collaboration across accountabilities within the Scrum Team, creating a shared responsibility on achieving that goal. It creates means of conversation about what to do next. And above all, it helps bring focus to the Sprint.

During the Sprint, the Sprint Goal is transparant for all to see. This is important to be able to work towards that goal, for instance during the Daily Scrum. During the Daily Scrum the Sprint Goal should be the main topic of conversation, creating a plan for the next 24 hours towards that goal.

The Sprint Backlog should consistently reflect the current progress of work towards the Sprint Goal and remaining work to be done. If there is work that is obstructing completion of the Sprint Goal, it best be removed from the Sprint Backlog.

Challenges with the Sprint Goal

So far the theoretical part. The question is now, what challenges do you encounter that relate to this subject? I have my own experience with Scrum Teams and also did some inquiries in the Scrum community to find out what teams are struggling with. Let's take a look at some of these real life - from the trenches - challenges!

With each of these challenges I share some things you could try to see if they help you improve. Remember, Scrum is an empirical process control mechanism. How to resolve and improve depends heavily on the context of the team and organisation. Some things may work for a specific team and not for yours. Or it's not the right time. But revealing them to the team you are working in or with may help you improve.

Let's get started:

Challenge #1: There is no Sprint Goal

When I started using Scrum years ago as a Developer and Scrum Master, the Sprint Goal was not top of mind for me. There were all kinds of other challenges way more prominent than not having a Sprint Goal. If the work got done, we were satisfied.

Asking around to common problems, this is one that pops up quite often. Not having a Sprint Goal might not block you from delivering a releasable increment or delivering value for your customers. However, a lot is gained when teams have focus on the Goal of the Sprint.

Tips to help improve this

The first major question that needs answering in this case is: what's the reason there is no Sprint Goal? This may be due to lack of knowledge, we simply don't know that the Sprint Goal in Scrum is significant. In this case a good conversation in your Sprint Retrospective could help. Also, the team might need some guidance in establishing the Sprint Goal during the Sprint Planning, because mostly there also is a lack of focus. We discuss the challenge of lack of focus later on.

Try to figure out by asking around and having constructive conversation with the Scrum Team about why there is no Sprint Goal. Any one of the challenges still to be discussed might be an underlying issue that needs to be resolved first.

Talk to the Product Owner (or if you are one, ask yourself this question): what is it that we want to achieve at the end of this Sprint? Talk to the team about this objective. Also, there are other stakeholders that would probably like to be able to see what the Scrum Team delivers at the end of the Sprint. A Sprint Goal makes more sense than a bunch of Product Backlog Items packed together.

This is a general tip:

Be patient. Change takes time. However, don't be hesitant to experiment. People are more eager to try something out and verifying the outcome (experiment) than they are open to enforced changes from the outside.

Challenge #2: The work is the Sprint Goal

So the next challenge to overcome, is a pitfall often taken when doing Scrum: sticking to the "rules of Scrum", but not knowing the reason for the rule being there.

This also is something I have done. I've told the Scrum Team: 'People, we need a Sprint Goal, because that's what prescribed by Scrum!'. And then if you are "lucky" and the team obeys, the Sprint Goal becomes: "Get Jira tickets 17322, 17323, 171400 and 17888 to done". 'Great, we now have a Sprint Goal. Back to work!'.

-or-

We take a close look at all the Product Backlog Items we selected for the Sprint and we try to squeeze these into a sentence that sums them all up:

"Finish the authorization issues, create a procedure for capturing search queries and make it generic, create a new theme for mobile version".

Product Backlog Items in the Sprint are the output that implement the Sprint Goal, the outcome. Meaning the Sprint Goal should be leading and not the Product Backlog Items in the Sprint.

Tips to help improve this

Product Owners should share their vision and what goals need to be achieved next. They should talk about it, share it, get feedback on it. Work with Developers on the Product Backlog to identify and create Product Backlog Items that will achieve this goal. Share and discuss this when the plan for this Sprint is drafted.

Often, Product Owners take the lead in Sprint Planning. And they should at first, but then they have to let the Developers self-manage how to achieve the Sprint Goal.

The key in this situation is to look at the way the work is organized. Is the Product Owner trying to keep all the stakeholders happy by giving them all a breadcrumb? Or are the stakeholders managed and is the Product Backlog organized around features that deliver value for customers at the end of the Sprint?

The Product Owner must be challenged on the status quo and Developers should take ownership on the plan that should have the Sprint Goal as outcome. They should discuss the Product Backlog Items that are taken into the Sprint and also look for alternative ways to achieve the Sprint Goal.

Challenge #3: There is no room for anything else

So the next challenge that arises happens often when we have overcome the previous challenges. We have a Sprint Goal, it's crafted during Sprint Planning in collaboration with Product Owner and Developers and the goal actually makes sense.

But there is no room for anything else. All the items on the Sprint Backlog are mandatory for accomplishing the Sprint Goal. And that's a problem. Because we know that there are problems that will occur:

The solution thought of turns out to be a lot harder to implement;
Production failures need fixing;
Danny (the guy everyone relies on) is ill (again!);
The Product Owner promised a particular stakeholder that he can get this last minute fix in the Sprint anyway.

... and so on ...

Having a full Sprint means imminent risk in achieving the Sprint Goal!

Tips to help improve this

I've been involved as a Scrum Master in a Scrum Team that used a primary and secondary goal in a Sprint, so that the focus remains on the main goal, but there is still cohesion on the rest of the Sprint. This may or may not work for your team. Shorter Sprints may be the answer here, but often organizations are not that flexible on the Sprint lengths. Choose your focus point for this Sprint. And make that your Sprint Goal.

Also, having so much work on your Sprint Backlog can challenge you to do things differently when things get tough and the Sprint goal gets jeopardized. But more likely it will cause teams to get stressed, have more focus on the work than on the actual Sprint goal.

Invest time in Product Backlog refinement. This will likely create better insights, multiple ways to solve things, smaller Product Backlog Items etc.

And to conclude, yes: give yourself (Developers) room to be creative and solve problems.

Challenge #4: There is no focus on the Sprint Goal

Having a solid, well understood, collaboratively crafted Sprint Goal is great, but it's not so great if you leave it behind Items mandatory for the Sprint goal in the room where it was born and is never brought up again.

Ask yourself the question what's the use of a Sprint Goal if it's never brought up again during the Sprint?

Tips to help improve this

Focus is one of the Scrum values and therefor important on a number of levels. This is definitely one of them. Having a goal helps create focus and this fosters collaboration. Collaboration improves quality and ultimately, that's what we need: good quality, valuable products for our end-users.

First step in overcoming this challenge is one of the most important things in Scrum: be transparent. Make sure the Sprint Goal is visible somewhere for everyone to see.

Secondly: talk about it. This sounds easier than it is. As soon as there is work to do we tend to focus mainly on the work and forget the goal. Scrum Masters reading this will recognize this. During Daily Scrum, make sure the Sprint Goal is the (only) topic of conversation.

Make sure Product Backlog Items on your Sprint relevant for the Sprint goal are on top and worked on first. Ask questions when it turns out people are working on other things. One team I worked with gave the Product Backlog Items that are relevant for the Sprint Goal a special color or tagged them otherwise. This works for them.

Challenge #5: The goal is not a goal

The final challenge teams face that we will discus is the goal not being a goal. It's important that the Sprint Goal has a -what- focus: what do we want to achieve? We don't need the -how- in there:

"Change the page to support HTML5 elements"

... is probably not the best Sprint Goal to work on.

Tips to help improve this

First of all, if you get to this level and the other challenges are behind you, congratulations! That's quite an achievement. Having a Sprint Goal, talking about it, having focus on it, giving room to inspect and adapt on it... you've come a long way!

This last challenge is a tough one, because there might be any number of challenges behind this that need attention.

Are the project or product goals worked on in your company clear to all? And as for the Sprint Goal: is this contributing to the overarching goals of the company? Formulating the Sprint Goal as really technical or on the -how- axes may be caused by underlying aspects of the organizational culture.

Maybe the accountabilities within the Scrum Team are not clear or not practiced. For instance: if a Product Owner is also a business analyst or a project manager, this will influence the way we look at our goals. Or maybe the company doesn't care about goals at all?

The Scrum Master role within Scrum is meant to reveal these organizational impediments. It takes time, patience and asking a lot of questions. But it will help the organization move forward toward achieving their goals.

Conclusion

In this "Scrum from the trenches" blog post we talked about the challenges of a Sprint goal. Thanks to some of you in the community for sharing your challenges and stories with me. Hopefully this blog post will help you figure out the next step in overcoming your challenges regarding the Sprint Goal.

Have you tried something else that worked for your team(s) and is not mentioned in my post? Please share it in the comments below!

footer

Scrum Facilitators is partners with Scrum.org and we’re accredited to teach all the Scrum.org courses. Check out our Scrum.org courses here.
Scrum Facilitators podcast on demand! Now you can listen to us at your own pace, in your own time.
Check out our free products that can help you improve your Scrum.
Join our Scrum Facilitators Community and interact with 100+ Scrum Professionals from all over the world
We have occasionally organised interactive meetups. Sign up and we’ll see you there ;)

What did you think about this post?

Share with your network

Comments (33)

Gaurav Khanna

01:54 pm April 8, 2018

Good article and really relates to the challenges with Coming up with a Sprint Goal. What a Sprint goal statement should look like ? Any guidelines for defining the Sprint Goal Statement. Does it also need to align with overall Product Vision

Jasper Alblas

06:29 am April 11, 2018

Hi Gaurav,

Thank you for the complement on my article.

I agree that the Sprint goal should align with the overall Product Vision, depending on if there is a vision and what it looks like ;) Also, the value is in the conversation. When a Sprint goal is set and it's in complete misalignment with the product vision the Scrum Team should have a discussion on this to see if this is the right Sprint goal to set for this Sprint.

There are some hints towards what a Sprint goal statement could look like or maybe shouldn't look like. There really is no rule. It's always interesting to have a discussion if the Sprint goal represents value to the customer :)

Randall England

06:44 pm April 12, 2018

Jasper, great article!

One of the many things I hate about using an electronic tool is that there is really no place to post the sprint goal. We put it on an internal page, but no one looks at it. I had the best success of my career using a whiteboard on wheels with post-it notes on it. At the top was our Sprint Goal for everyone to see every day. The whiteboard was in the teams work area and we wheeled it into our ceremonies. It put the goal in front of everyone so we talked about it at every meeting. At my current job we use an electronic tool and it is not feasible to do this.

I miss those days.

Guilherme Krüger Romariz

07:48 pm April 16, 2018

Thanks for this article, Jasper.
Im now studying for PSPO but I worked one year here in Brazil with IT area that used SCRUM.

Frequently we had sprints to correct different functions of the system. A sprint can have more than one Sprint Goal? Is this possible?
Or, when we are talking about only corrections, do we need a Goal?

Tim Baffa

04:04 pm April 27, 2018

Excellent article Jasper.

In my experience, the teams I've served have all struggled with coming up with Sprint Goal statements. Regarding verbiage, I've tried to coach them to express their goals in more generic "what" value-statements, using terms like "improve", "provide", "display", and "allow" for example, with a good deal of success.

It provides a clear elevator-pitch type statement that everyone should be able to understand, and allows a number of items to fit under the sprint goal statement which allows for the sprint goal to be reached even if one of the items has issues.

Erik Buitenhuis

11:22 am September 20, 2018

why not use both?

Sergey Shamin

04:52 pm February 2, 2019

the same question I had in my mind too - our current sprint for example is about adding many small things in different parts of application - and I guess it is hard to formulate general goal of sprint, other then 'add some more functionality...'

sjoerdly

08:45 pm February 12, 2019

Hi Sergey, what is the value in, or reason for adding these many small things? It could be to improve overall usability, or security enhancements, etc. Dig a bit deeper into WHY these many small things are done THIS sprint, instead of other things. HTH

sjoerdly

08:48 pm February 12, 2019

I used to work on a Scrum team where we actually had both. And I would recommend any team using strictly digital tools to put up a (large) monitor featuring the current Sprint Backlog, including big ass Sprint Goal (readable from the moment you enter). We had it rotating with test status, integration reporting, live load and usage stats etc. The dev team loved to spice it up with useful info and the visitors, Stakeholders and other people always became curious about the contents of the screen sparking many useful conversations.

Siva

01:25 am June 25, 2019

I have a question if I may. For teams that do operational work (Not S/w development), how do teams go about setting a goal. The teams are procurement teams. They work with requesters for products and services and with suppliers to fulfill the requests.

Martin L Simmons

01:16 pm July 11, 2019

What could be really helpful are a few generic examples of (SMART) goals, so we can see what best practice looks like. Thanks. MLS

ya sim

03:50 pm September 17, 2019

Still the main problem is not being addressed. It seems formulating Sprint Goal to be any different than the list of committed PBI leads to shifting focus from achieving goal of approvals for all Acceptance Criteria in that list. "Sprint Goal" might be an additional info explaining why PBI-s were selected to the Sprint, but should not set any other goal, agree?

gayathri ganesamurthy

04:35 pm July 1, 2020

I have used Sprint goals in the past and it has worked very well when I have worked with smaller (4 members) scrum teams. Some of my current teams are larger than that, 8 members. While we have matured enough to overcome all the other challenges, the only one we are left with is as follows.
When you commit to a goal that allows a meaningful functional increment, it often means the same areas of the product need to be worked on, and this is technically challenging as its not possible for multiple team members to work on the same classes etc, even if the Sprint backlog item itself can be broken down meaningfully. Any ideas to overcome this would help us to get back to using Sprint goals. We now end up working on different features/functions in a single Sprint.

Mayumi Matayoshi

03:25 am July 20, 2020

Does this mean each Sprint has its own individual goal? Does the overall end-product have one goal, therefore there is one HUGE goal and then subgoals?

Bruno Torelli

12:42 pm July 24, 2020

Hi Sergey! In these cases, I usually question the Scrum team. Why these "small things" are being demanded, the common thread in the answers will be my goal in the SMART Sprint Goal.

Sujit

12:57 pm July 24, 2020

Hi Siva,
Just from the above article and one of the comments given by Tim Baffa, considering your scenario, the Sprint Goal could be more generic. For instance, The Sprint Goal could be "As a team, we would be committing to improve on the SLA for procurement of certain products, in the current Sprint" or "As a team, we would be providing or sending the desired invoices in a more streamlined manner, in the current Sprint"
I am not sure if this helps, but just a thought! Probably you can build up on similar lines.

Sujit

02:03 pm August 17, 2020

When we work in Sprints, we generally craft new sprint goals depending on the work items pulled from PB into Sprint backlog. So ideally, every sprint we come up with a new sprint goal. To address your second question, if the overall end product has one HUGE goal then it is more likely referred as the end vision. Having said that visions are likely to change over the due coarse of time depending on the market conditions or technological aspects or say if company changes directions to adapt new things.

Sujit

02:15 pm August 17, 2020

Yes, it can have more than one sprint goal if there is more than one team, working on the same product.
In my past projects, where we followed the SAFe Agile framework, wherein multiple teams collaborated in a PI planning meeting, working on the same product, pulling items from same product backlog. Now each team used to frame their own sprint goal depending on the items undertaken for development in the subsequent sprint.
I am not of the opinion of having two different sprint goals for one team. This is because, if there is more than one sprint goal for a team, then, the SCRUM value of 'Focus' may be faltered. This may affect the teams 'Commitment' to deliver a quality product and the goal might not be achieved.

P.S. please feel free to enlighten me if anything is amiss.

Liis Monson

11:54 am January 14, 2021

Have you considered splitting the team into 2 scrum teams with common PO and SM? In which case the Product Goal and Backlog are shared, but they can very well work towards different Sprint Goals...

Incremint

10:10 am August 20, 2021

This is definitely a good read.

Karina

05:03 pm September 10, 2021

Many thanks for sharing these valuable tips.
I have a question:
What if there’s a product intended for developers, all stakeholders have extensive development experience and the product owner is also with a technical mindset.
This all results in goals and all backlog items being quite technical and often describing the “how”- as in 5th challenge.
Does it make sense to change that? How would you address this challenge?

Ralf Stemmer

02:41 pm November 11, 2021

Let's say I have a product backlog with PBIs ordered by priority. When doing a sprint planning I come up with a sprint goal. That gives me two different ways of prioritization. If I choose the top 4 PBIs and try to give it a more general name, that does not seem to be a good way of defining a sprint goal for me, that would be #2 the work is the sprint goal. Any ideas or hints how to resolve that? Thanks!

Gustavo Gonçalves

09:46 am January 25, 2022

What's the best way to manage and create value in the backlog when it's the client who prioritizes what needs to be done?

Raj Thevar

11:19 am May 12, 2022

Please correct a type in 3rd paragraph last sentence - FROM "And if gives purpose to the current Sprint" TO "And it gives purpose to the current Sprint" :)

Shishir Jathar

06:46 am July 11, 2022

I have a question regarding the sprint goal. First let me explain the scenario.. the project is already live and now the enhancements are coming in different areas in bits and pieces, there are some defect fixes, technical debt tickets, all happening in a sprint. It is really hard for the team to set a particular sprint goal.

In this scenario, is it really important to set a sprint goal just because scrum guide recommends it?

N Murali Mohan

03:11 pm November 30, 2022

Nice article! Thanks for writing it clearly and in an engaging manner.

John Hamel

05:51 pm December 2, 2022

Grammer/typo:
"satisfaction. And if gives purpose to the current Sprint." should be
"satisfaction, and it gives purpose to the current Sprint."

John Hamel

07:59 pm December 2, 2022

Also, "therefore" not "therefor."

Nazar MELNYK

05:01 pm October 26, 2023

Hi,
Could you please advice how would you call the Sprint Goals in a case, when:
- there is large piece of work (e.g. Integration with Google Analytics),
- this piece of work cannot be done within one sprint
- thus is divided into several tickets having the same target but their own microscopes (e.g. Integrate AAA with Google Analytics; Integrate BBB with Google Analytics, etc.)

Would it be like:
Sprint S Goal: "Integrated with Google Analytics (Step 1/2)"
Sprint S+1 Goal: "Integrated with Google Analytics (Step 2/2)" ?

Thank you in advance :)

Bodo Runde

02:50 pm November 1, 2023

No responses after one year? Then I will share my thoughts:
First I would check if it is really still in development. Scrum is really useful for development for maintenance I prefer Kanban, as it is easier if you don't have a common development focus in your team.
Let's assume there are still some new features of other customer benefit - then you could go with scrum. As the article states never fill the sprint to tight with work. You could end up spending 25% of the time for a meaningful benefit and use this as the sprint goal. The rest of time the team takes care for defect fixes and so on.

Bodo Runde

03:02 pm November 1, 2023

It's one idea to come up with step 1 and 2. Let me suggest another breakdown:

Sprint S Goal: "Implement analytics on the main points of interest"
Sprint S+1 Goal: "Roll out the analytics on the whole webpage"

My arguments to use this as an improvement are:
1. Sprint goals become independent. If you decide otherwise for S+1 you still have useful analytics. (Having only AAA might be insufficient.)
2. You focus on the result - using Google Analytics is part of the how and not necessarily what.
3. The scope remains negotiable. Let's say you aimed for 30 main points of interest but had some issues during the sprint. Covering only 19 points of interest might still bring a benefit.

Still the customer focus could be improved more in both sprint goals. Like "provide the analytics with insight of ..."

Larissa Gama

07:13 pm February 6, 2024

Good read! I think this is great content, but at the end of the day, can be very difficult to set a sprint goal if you have incremental developments that do not necessarily bring immediate value to the stakeholder. For example: I will implement a new tool for stock management, and the first delivery just covers part of the architecture needed in a single sprint, what should be my goal? delivery half of architecture? This happens especially if you have a short timebox, like 2 weeks, and can be even worse if you have a technical dept or any other urgent development on top of your product backlog.

Sarah

05:45 am August 27, 2024

"The Product Goal describes a future state of the product which can serve as a target for the Scrum Team
to plan against. The Product Goal is in the Product Backlog."

"The Sprint Goal is the single objective for the Sprint. The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind."

- The Scrum Guide 2020