Scrum from the trenches - the Sprint goal

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 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 37 times in the Scrum guide in different contexts. Although it's not part of the core elements of Scrum (Roles, Events and Artifacts), having a Sprint goal is of great importance for achieving your overall business objectives and customer satisfaction.

The Sprint goal is crafted in during the Sprint planning and fosters collaboration between the Development Team and the Product Owner, 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 for the theoretical part. The question now is, what challenges do you encounter that relate to this subject? I have my own experience with 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 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 goal. 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 Sprint 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 team: 'Guys, 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 Sprint Backlog Items.

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. Then invite the Development Team to pull work from the Product Backlog (and maybe create some Sprint Backlog Items as well) 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 Development Team self organize around the Sprint goal. You might be surprised at the results!

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 functional components that deliver value for customers at the end of the Sprint?

The Product Owner must be challenged on the status quo and the Development Team 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 Development Team 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 have had one team use 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.

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 / the Development Team 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 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 discussed.

Make sure Sprint 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 work with gives the Sprint Backlog Items that are relevant for the Sprint goal a special color or tags 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 Scrum roles (and responsibilities) 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!

Next post in "Scrum from the trenches" will be on Product Backlog refinement!