Myth: Having A Sprint Goal Is Optional In Scrum

Myth: A Sprint Goal Is Optional In Scrum

In this series of posts, we—your Mythbusters Christiaan Verwijs and Barry Overeem—address common myths and misunderstandings. Thea Schukken created the great visuals.

Does your Scrum team use Sprint Goals? If not, why? Your team may struggle to identify a Sprint Goal from the patchwork of items on the Sprint Backlog. Or perhaps your Product Owner doesn’t know how to balance the requests from many stakeholders.

In this post, we bust one of the most persistent myths in Scrum: the notion that Sprint Goals are optional. They are nice to have but hardly ever practically possible. We will show that the reverse is true. It is tough, maybe even impossible, to do Scrum well when you don’t have Sprint Goals.

You can also listen to this post in this episode of our podcast ‘The Liberators Network’.

Busting The Myth

Let's begin by revisiting the Scrum Guide. It starts by explaining that the Scrum Team crafted the Sprint Goal during Sprint Planning, usually based on an objective defined by the Product Owner. The guide goes on to clarify that a ‘Sprint Goal’ is an objective for the Sprint that will be met through implementing selected work from the Product Backlog. It “offers guidance to the team on why it is building the Increment.” Instead of prescribing a format for Sprint Goals or how to craft them, the guide emphasizes that “The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. But the Sprint Goal can be any other coherence that causes the team to work together rather than on separate initiatives”.

“The Sprint Goal can be any other coherence that causes the team to work together rather than on separate initiatives” — Scrum Guide.

Interestingly, ‘Sprint Goal’ appears 27 times in the Scrum Guide. Of all the elements that make up the Scrum framework, only Sprint (173), Increment (47), and Done (40) appear more often. Sprint Goals are also specifically referenced for the Scrum events. Sprint Planning is used to craft a Sprint Goal. The team uses the Daily Scrum [..] to inspect progress toward the Sprint Goal”. The Sprint Review is about inspecting the Increment that resulted from work on the Sprint Goal, while the Sprint Retrospective is about inspecting how the team collaborated to do that work. To further emphasize the point, the guide notes that “Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.”

This helps us understand three important purposes of Sprint Goals:

1. They give guidance during the Sprint on the objective that the Scrum Team wants to achieve in the Sprint, as well as why that is important;
2. They help the team focus on what (kind of) work is important and what is not;
3. They promote collaboration by giving teams one clear purpose to work on instead of separate initiatives;

We now know that Sprint Goals are vitally important in explaining the Scrum framework in the guide. But that doesn’t immediately tell us why. Let's see what happens when teams don’t work with Sprint Goals.

Optional note: Some people wonder why the Sprint Goal is not an artifact in Scrum if it is so important. Although this question has merit, a deeper Scrum exegesis focuses too much on the framework instead of its underlying purpose. Having a Sprint Goal is one of the rules of Scrum, as is having a shared understanding of “Done.” Neither are ‘artifacts’ according to the framework, but both are incredibly valuable to navigating complexity and all the potential confusion that entails.

What happens without Sprint Goals …

The Scrum framework is built on the observation that product development is complex work involving a lot of problem-solving. Sprint Goals are very important there. So, let’s do a thought experiment and imagine a team that doesn’t use Sprint Goals. You’re likely to observe:

• Without a clear and shared objective for the Sprint, many items will be pulled from the Product Backlog during Sprint Planning. The items will be a patchwork, representing different groups of stakeholders, different functional areas, or even entirely different products or platforms. In effect, the Scrum Team is implicitly creating many different promises to many different stakeholders (Product Owner included);
• Without a shared objective known to the team and its stakeholders, the Sprint Backlog is likely what teams implicitly (or explicitly) commit to instead. Each item promises something to deliver by the end of the Sprint, regardless of its value. Scrum Teams are likely seen as “feature factories,” churning out streams of unrelated features, instead of “product development teams”;
• Without a clear shared goal and feeling the pressure to complete a Sprint Backlog full of unrelated items, there is no obvious incentive to collaborate. Instead, you will likely see team members picking up ‘their own’ items from the Sprint Backlog and starting work on that. Self-organization will be limited, and members will remain (or become increasingly) specialized in particular kinds of items;
• With everyone in the team working primarily on their items, the Daily Scrum takes the form of a status update where members announce what they’ve been working on and what they plan to work on. You will hear more “I” than “We”. Communication will be more about taking turns than actively devising a collaborative strategy that involves multiple members (e.g., “If we do this … then I can …. so that you can … “);
• Without a shared objective and everyone working mostly on their items, members will complete ‘all their work’ at different moments during the Sprint. Without a shared objective to encourage people to identify opportunities to help each other, they will announce they have nothing to do. They start work on items elsewhere on the Product Backlog, over-engineer, or spend time on work that is not relevant to the team;
• Knowing who to invite for the Sprint Review is hard without a clear objective. Although some stakeholders may show up to inspect individual items implemented for them, they also have to sit through all the other items being discussed. Without a way to explain the purpose of this Sprint to stakeholders other than ‘completing all the work,’ stakeholders are likely to be increasingly less inclined to make this time available.
• During the Sprint, unexpected problems, uncertainties, and issues will likely arise and require more time. With time being a purposefully scarce resource in a Sprint, and without a clear and shared objective, the team doesn’t have guidance on deciding where to invest time and what to let go (for now). Everything will likely be considered equally (un)important, resulting in more uncompleted work;
• Without a clear and shared objective for Sprint, it is hard to know when it will be successful. A clear goal can be achieved and then celebrated. But without such a goal, completing the entire Sprint Backlog often becomes the goal. With software development being rife with unpredictability and emerging issues, most Sprints will likely have unfinished items left on the Sprint Backlog by the end of the Sprint, meaning there are hardly ever any opportunities to celebrate;
• People will likely complain that Scrum events take time and feel ineffective. Without a clear and shared objective that ties all the conversations together, Scrum events will be experienced more like ‘meetings’ where there’s a lot of talking going on that is not relevant to everyone;
• Without Sprint Goals, each Sprint implicitly has the same purpose: complete all the work. This makes all Sprints the same and can make people (rightfully) complain that they are artificial;

You are not alone if you recognize some of these in your teams. Most of the reasons why Scrum Teams and organizations struggle with Scrum can be traced back to missing Sprint Goals and not understanding the reasons for working with Scrum.

“A Sprint is [ … ] the smallest possible time-box for a Scrum Team to deliver a coherent set of valuable features without losing focus”

The Scrum framework proposes to reduce the risks of complex and unpredictable work by working in small steps. Each step is a time-boxed ‘experiment’ that helps us make visible what other work is necessary. The most useful experiments here are those that make us deliver something valuable to stakeholders and learn from their feedback. A Sprint is the “smallest possible time-box for a Scrum Team to deliver a coherent set of valuable features without losing focus.” Instead, Sprints are often considered arbitrary containers to “fill with work.”

Sprint Goals are intended to help organizations break free from this output-driven approach, which focuses on efficiency and getting as much work done as possible by focusing on valuable outcomes and an experimental mindset. Let’s explore some examples of Sprint Goals to see how this is done.

Intermission: Examples of Sprint Goals

We once worked with a Scrum Team that developed a product for flex workers to track time and get paid. The submitted hours were then validated by employees for flex agencies and processed for payment. Although we had access to users and domain experts, we used Sprints to learn how to build this product and identify additional features. Below are the Sprint Goals for the first three Sprints:

Sprint 1: “This Sprint exists to set up our deployment infrastructure to deploy a secure, working login page.”

We started the first Sprint with an empty canvas. With only two weeks to go and aiming to deploy to production continuously, we decided to focus on setting up and configuring all the required infrastructure (servers and code) to deploy a working login page. This also required us to implement OpenID and secure the application.

Sprint 2: “This Sprint exists to use-test the interface for entering hours”

For the second Sprint, we were eager to test our ideas for creating a more user-friendly hour-registration interface — one of the product's competitive advantages. Going into the Sprint, we only had a rough sketch from our designer. We pulled all the required work from the Product Backlog (design, testing & deployment included) that we could complete in a Sprint. However, we soon discovered that creating the interface took far longer than expected. So, we worked with the Product Owner to narrow the scope of the Sprint Backlog and decided to focus only on entering hours for the current week.

Sprint 3: “This Sprint exists to allow flex agency employees to validate the hours submitted this week.”

For the third Sprint, we wanted to expand the workflow by allowing employees from flex agencies to log in and validate submitted hours. During the Sprint, we encountered many issues with our authentication platform (OpenID). The team members swarmed on this issue, with a member from another team also jumping in. Sustained development continued for another 16 Sprints, and the product is still in use.

These imperfect examples illustrate how Sprint Goals are not a result of a Sprint Backlog but their starting point. Before starting development on the product, we spent time with the team identifying likely objectives for the first Sprints.

Reasons for not having Spring Goals

Up to this point, we’ve seen how important Sprint Goals are to Scrum. We’ve also seen some examples. Yet, most teams don’t use them. Below are some of the reasons we hear most often:

• Product Owners are not mandated to decide what goes on the Product Backlog and in what order. Instead, they are required to pass on “feature requests” or issues from stakeholders;
• Product Owners don’t have a vision or strategy for the product that guides the formulation of objectives and Sprint Goals;
• Scrum Teams struggle with formulating objectives and Sprint Goals when their Product Backlogs span thousands of items. How do you decide what is important then?;
• Scrum Teams may be too large, making stakeholders and the Product Owner scramble for enough work to keep everyone busy;
• Scrum Teams may work on different products or projects at the same time, making it hard to identify one singular goal for a Sprint;

“Scrum Teams may work on different products or projects at the same time, making it hard to identify one singular goal for a Sprint.”

• Sprints may be too short or too long, making it hard to define concrete, tangible Sprint Goals that can be achieved within a Sprint;
• Scrum Teams may be organized as ‘component teams’, working only on certain layers or components of the application (e.g., database, a specific web service, or the UI). This makes it hard to craft Sprint Goals that explain the functional purpose of a Sprint;
• During Sprint Planning, Scrum Teams often start with the Sprint Backlog and try to reverse-engineer a Sprint Goal from there;
• Some teams do work unsuitable to the time-boxed and purpose-driven nature of Sprints. For example, Support Teams that are responsible for many different products or services probably won’t benefit from using Sprints as ‘value-creation timeboxes’;

You may find yourself, your Scrum Team, or your organization using one or more of these reasons. Save perhaps for the last one, each of these impedes working empirically.

Tips

Helping Product Owners think in terms of objectives for Sprints, and then turning them into Sprint Goals together with the Scrum Team is challenging. However, taking this challenge head-on is vital to working empirically with Scrum and creating high-performing Scrum Teams instead of ignoring it. The following tips help:

• Help Product Owners plan by identifying potential objectives for upcoming Sprints. We like to ask Product Owners to tell the ‘story of their Sprints’: “First, we will [objective A] to allow us to [objective B] so that we can [objective C] … ” and so on. Then, identify what items should go on the Product Backlog to make those objectives possible. This helps shift Product Owners and teams more into a strategic mode than simply listing all the work;
• You can use the Liberating Structure Nine Whys during Sprint Planning to help Scrum Teams determine the purpose of the Sprint. You can use the items on the top of the Product Backlog and keep asking, “Why are these important to you…?”;
• As a Scrum Master, you can ask powerful questions to help Product Owners dig deeper into the “Why” of their decisions, like: “If the entire Product Backlog was lost, what would be the first things you would bring back at this moment in time? Why?”, “What do you hope this objective makes possible for stakeholders or in this organization?” or “What opportunity would be lost if we don’t do this item this Sprint?”;

“If the entire Product Backlog was lost, what would be the first things you would bring back at this moment in time? Why?”

• The Sprint Review offers potential objectives for the next Sprint(s) when you use this event to gather feedback from stakeholders and debrief together. A Liberating Structure like What, So What, Now What is helpful here because it asks groups to start from observations, then interpret those, and finally decide on potential next steps that make sense;
• Use a template to craft Sprint Goals: “This Sprint exists to…” or “This Sprint, we promise to … “. Generally speaking, this sentence shouldn’t contain ‘and’ or commas to chain together multiple objectives;
• Make your Sprint Goal transparent by hanging it in the Team Room or above the Sprint Backlog. Roman Pichler has created a nice template for crafting Sprint Goal that can help you do this;
• Begin each Scrum Event by stating the Sprint Goal and by tying it to the purpose of the event;
• Don’t worry if you can’t relate all the items on a Sprint Backlog directly to the Sprint Goal. Sometimes, there may be a compelling reason to do some work for this Sprint even though it doesn’t align with the Sprint Goal (e.g., a planning issue or an external dependency). Be skeptical of accepting such work, though, and ask, “What is lost if we make this next Sprint?” or “How will we make sure to keep the focus on the Sprint Goal?”;
• Suppose your work does not involve software- or product development. In that case, the Scrum Guide gives guidance by stating that a Sprint Goal can be “any other coherence that causes the team to work together rather than on separate initiatives.” In other words, find Sprint Goals that offer guidance during the Sprint and promote collaboration in your team;

“Find Sprint Goals that offer guidance during the Sprint and promote collaboration in your team.”

Concluding thoughts

When teams start working with Scrum, working with Sprint Goals is often at the end of the list of things to do. Most of the Scrum Masters we meet in our classes and work with admit that they don’t use Sprint Goals with their teams. It's often experienced as too hard, too difficult, and sometimes “impossible in our organization.” It's easier to start with the roles, artifacts, and events.

This post showed how Sprint Goals are integral to how the Scrum framework helps teams navigate complex work. By its very nature, complex work requires teams to continuously decide about value, what to spend time on, and what to let go of (for now). Sprint Goals offer much-needed guidance for the decisions. Without them, the whole framework unravels; Scrum events lose their purpose, Scrum Teams have little reason to collaborate, and organizations don’t start to think in terms of value.

“The lack of Sprint Goals is one of the biggest impediments facing Scrum Teams today.”

The lack of Sprint Goals — a singular purpose for a Sprint — is one of the biggest impediments facing Scrum Teams today. Although creating them is initially sometimes incredibly hard, it's exactly the kind of challenge that Scrum Masters should go looking for. We encourage you to do so!