How can I effectively differentiate the Sprint Goal from the Sprint Backlog?

Question

I'm facing a situation where I have to explain with an example the difference between a Sprint Goal and a Sprint Backlog. Here's how I understand it:

1. The Sprint Goal is an objective that needs to be achieved by the team during the sprint through the implementation of part of the Product Backlog.
2. The Sprint Backlog is a stream or set of items from the Product/Release Backlog that are to be worked upon and some of it which will help achieve the Sprint Goal.

For example, a team is building a ratings feature for a product item on sale at an e-commerce website.

• Feature 1:, As a user, I want to leave a rating for an item I have purchased.
• Feature 2: As a user, I want to view ratings given by other users who have purchased a product.

Now the Sprint Backlog could be a mix of User Stories for each of these:

• features
• defects
• tech debt
• spikes/research/proofs-of-concept, etc.

but the Sprint Goal for each Sprint should be from the user's perspective. For example, goals for four different Sprints might be:

1. Sprint Goal:
   • Users should be able to see a list of stars against each product.
2. Sprint Goal:
   • Users should be able to give a rating to each product.
   • Users should be able to view ratings of other users.
3. Sprint Goal:
   • Users should be able to change the rating at any given point of time.
   • Users should not be able to change other users' ratings.
4. Sprint Goal:
   • Users cannot rate products that have not yet been purchased.

How can I better explain the difference?

Answer 1

There is a single sprint goal, to prioritize the sprint backlog. The team goes about what the do and when, but they need guidance. The goal is not from the user's perspective, the goal is about what the PO wants to achieve with this sprint. That might be something from the user perspective. It might not.

Having sprint goals in advance is counterproductive. It basically says you are not acting agile. If you make a 6 months plan, then you can do that, but those forecasts are not sprint goals. A sprint goal is something agreed on in the sprint planning just before the sprint because you can never know what bug or change in plans will come up.

In your example, a valid sprint goal could be to finish the feature. So they do the defect stories and technical debt last and maybe if the forecast wasn't perfect, those drop off the list and are not finished at the end.

In your example, a valid sprint goal could also be to fix that one defect that was found, that is hindering the sales people with the live system to make money. If the rating system does not get done, that's okay, it's top priority that the checkout bug gets fixed this sprint.

I'm not sure if it's entirely by-the-book Scrum, but we have had Sprint goals that had nothing to do with stories at all. The only point of the sprint goal is that when in doubt what to prioritize, the team can make a decision based on a communicated, single goal.

Answer 2

TL;DR

This is a good question because it exposes a common misunderstanding about Scrum theory and the value of a Sprint Goal. To illustrate your use case, though, you'd need to craft a Product Backlog from which the Scrum Team can extract backlog items that fit a central coherence. A Product Backlog that doesn't lend itself to unified Development Team efforts is a framework implementation smell that should be addressed ASAP.

Sprint Goals Provide Context and Scope

I am going to take a slightly different tack than the other answers. The Sprint Goal is not a sort of "meta user story" told from an end-user's perspective.

Intrinsically, the Sprint Goal has nothing to do with the end-users' perspective. Scrum theory explains the Sprint Goal as follows (bold emphasis mine):

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

Too many times, I see Scrum Teams treating the Sprint Goal as an implicit "do all the things on the Sprint Backlog" as their Definition of Done for the Sprint. Of course, that's assuming they bother to craft a Sprint Goal at all. The Sprint Goal must be explicit, and having one for each Sprint is required by the framework.

Even worse than not defining a Sprint Goal is having a Scrum Team that crafts multiple Sprint Goals per Sprint. In practice, a Sprint Goal is a singular coherence that provides context and scope for the Sprint.

Product Backlog Items that don't fit the Sprint Goal, or Sprint Backlog items that aren't required to deliver the current Sprint Goal or create process improvements (including "last responsible moment" architectural runway and Sprint Retrospective items) should not be selected for the Sprint in the first place!

A real Scrum Team is always working on a singular goal each Sprint, although that goal may have multiple collaborative or parallel elements. Even if there are parallel elements, though, a Sprint that doesn't have both a central coherence and eventual integration within the current Sprint isn't really Scrum.

Answer 3

I think that nvoigt's answer is solid. I will add a few things.

I see the Sprint Goal as a way for the Development Team to not need constant interaction with the Product Owner.

Consider that the Sprint Goal is created during Sprint Planning as a collaboration between the Development Team and the Product Owner and helps to guide the selection of the Product Backlog Items for the Sprint Backlog. Also, as part of Sprint Planning, the Development Team begins to create a plan for getting those selected Product Backlog Items to Done.

Throughout the Sprint, the Development Team will continue to plan out their path to achieving the Sprint Goal. Having a singular Sprint Goal helps keep them focused. If they find out that certain things are going to be more complex or they discover work that was previously unknown, they can look at their goal and ask themselves how they intend to meet it. As long as they are able to deliver it before the end of the Sprint timebox. As long as they are reasonably confident that they can meet the Sprint Goal, they can generally be left to plan and execute on their own.

When the Sprint Goal is in jeopardy, then the Development Team can seek more active involvement from the Product Owner to figure out how to deliver the most value for that Sprint based on what is now known.

Of course, this doesn't mean that the Development Team works in a silo, isolated from the Product Owner. That would be inherently un-Agile since one of the principles of the Manifesto for Agile Software Development is the Development Team and business people working together every day.

---

What constitutes "reasonably confident" depends on the organization. Some organizations are less tolerant to risk or have reasons to focus more on showing progress in terms of delivering work than others. There's no good singular definition.