Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve complex problems with an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths. In this series of posts we — your ‘Mythbusters’ Christiaan Verwijs & Barry Overeem — address common myths and misunderstandings. The great visuals are by Thea Schukken. You can find previous episodes here.
Does your Scrum Team use Sprint Goals? If not, why? Perhaps your team is finding it hard to identify a goal for the Sprint out of the patchwork of items on the Sprint Backlog? Or perhaps the Product Owner doesn’t know how, being unable to balance requests from many different groups of stakeholders?
In this post, we bust one of the most persistent myths in Scrum; the notion that Sprint Goals are optional in Scrum. A practice that is nice-to-have, but hardly ever practically possible. We will show that the reverse is true.
Busting The Myth
Let's begin by revisiting the Scrum Guide. It starts by explaining the Sprint Goal is crafted by the Scrum Team 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 Development 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 Development Team to work together rather than on separate initiatives”.
“The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives” — Scrum Guide.
It's interesting to note that ‘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 Daily Scrum is used by the “The Development Team [..] 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. And 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:
- 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;
- They help the Development Team focus on what (kind of) work is important, and what is not;
- They promote collaboration by giving Development Teams one clear purpose to work on, instead of separate initiatives;
We now know that Sprint Goals are vitally important in how the Scrum Framework is explained by 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 its so important. Although this question has merit, we feel that a deeper Scrum exegesis puts too much focus 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 navigate 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 apparently very important there. So let’s do a thought experiment and imagine a team that doesn’t make use of Sprint Goals. You’re likely to observe:
- Without a clear and shared objective for the Sprint, a wide variety of 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 there being a shared objective, known both to the team and its stakeholders, the Sprint Backlog is likely what Development Teams implicitly (or explicitly) commit to instead. Each item acts as a promise of 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 are likely to see members of the team 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 mostly on their own 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”. And 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 with everyone working mostly on their own 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 instead 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;
- Without a clear objective, it is hard to know who to invite for the Sprint Review. 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’, it's likely that stakeholders will be increasingly less inclined to make this time available.
- During the Sprint, unexpected problems, uncertainties and issues are likely to arise that require more time. With time being a purposefully scarce resource in a Sprint, and without a clear and shared objective, the Development Team doesn’t have guidance on how to decide where to invest time and what to let go (for now). It is likely that everything will be considered equally (un)important, resulting in more uncompleted work;
- Without a clear and shared objective for the Sprint, it is hard to know when a Sprint is 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, it is likely that most Sprints will have unfinished items left on the Sprint Backlog by the end of the Sprint, meaning there are hardly ever any opportunities to celebrate;
- People are likely to complain that Scrum Events take a lot of 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 certainly 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 — behind that — 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 to 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 understood merely as arbitrary containers to “fill with work”.
Sprint Goals are intended to help organizations break free from this output-driven approach, where the focus lies 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 for it. 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 to identify additional features as we went. 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 (both in terms of 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 competitive advantages of the product. 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 more time 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 the authentication platform we used (OpenID). Members of the team 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 examples, though not perfect, illustrate how Sprint Goals are not a result of a Sprint Backlog, but rather their starting point. Before starting development on the product, we already spent time with the team to identify likely objectives for the first Sprints.
Reasons for not having Sprint 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 don’t have the mandate 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 the formulation of 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 Goal 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 that is not suited 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 is an impediment to 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. But taking this challenge head-on, instead of ignoring it, is vital to working empirically with Scrum and to create high-performing Scrum Teams. The following tips help:
- Help Product Owners plan ahead by identifying potential objectives for upcoming Sprints. We like to ask Product Owners 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 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 make good use of this event to gather feedback from stakeholders and to 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 made sense;
- Use a template to craft Sprint Goals: “This Sprint exists in order to …” or “This Sprint, we promise to … “. Generally speaking, this sentence shouldn’t contain ‘and’ or comma’s to chain together multiple objectives;
- Make your Sprint Goal transparent by hanging it in the Team Room or putting it 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 this Sprint even though it doesn’t align with the Sprint Goal (e.g. a planning issue or an external dependency). Be sceptical of accepting such work though, and ask “What is lost if we do this next Sprint?” or “How we will make sure to keep the focus on the Sprint Goal?”;
- If your work does not involve software- or product development, the Scrum Guide gives guidance by stating that a Sprint Goal can be “any other coherence that causes the Development 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 very end of the list of things to do. Most of the Scrum Masters we meet in our classes and work 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”. Its easier to start with the roles, artifacts, and events.
In this post, we showed how Sprint Goals are an integral part of how the Scrum Framework helps teams to navigate complex work. By its very nature, complex work requires teams to continuously make decisions about value, what to spend time on what 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!
