The Sprint Goal is one of the most fundamental, yet overlooked and misunderstood components of the Scrum framework. As a matter of fact, the Scrum Guide hinges on the Sprint Goal so much that it states, “A Sprint would be cancelled if the Sprint Goal becomes obsolete”! I sheepishly admit that I’ve not been a good steward in this regard – most, if not all, of my recent Sprints have had watered-down or meaningless Sprint Goals.

So, let’s get back to basics and take a few minutes to study the  Who, What, When, Where and Why regarding this often disregarded concept.


So, who should set the Sprint Goal?

According to the Scrum Guide, “After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal”. This indicates that the ENTIRE team is responsible for creating the Sprint Goal.

So why does there seem to be so much confusion about this in the Agile community? One blogger writes that, “The product owner can choose the goal beforehand to help her order the backlog according to the goal. Alternatively the whole team can phrase the goal at the end of planning, when they know which stories will be part of the sprint.” Clearly, the Scrum Guide says otherwise. This glossary also states, “A high-level summary of the goal the product owner would like to accomplish during the sprint.” Again, not true.


And, what is the Sprint Goal anyways? Good question! Once again, let’s refer to the Scrum Guide. “The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog…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.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.”

So, the Sprint Goal is the higher purpose that over-arches the Sprint Backlog. Put simply, it is the most important deliverable during the Sprint – it should be top of mind throughout every facet of the Sprint. One blogger even noted that it’s often possible to deliver the Sprint Goal WITHOUT completing all of the Sprint Backlog items.



Alright. We now know What the Sprint Goal is and Who sets it, but When is this done? The Scrum Guide says, “After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal”. This seems to indicate that the user stories for the Sprint are first chosen and THEN the Sprint Goal, which ties them all together, is derived. But does that make sense? Is it wise to choose your path before you even know where you’re going? This blogger agrees with my logic, “I first select the goal. Then I explore which epics have to contribute to it, and I break out small detailed stories from the epics. Finally, I order the new ready stories based on their contribution to the goal.” This makes sense to me. As Ebenezer Ikonne (eikonne) so wisely queried over HipChat, “Which comes first, Goal or Tactic? 🙂 ” But UrbanTurtle disagrees, claiming, “It is best to define a sprint goal after all the stories have been selected for the sprint. It’ll be easier for the team to craft the sprint goal together since they have a better understanding of the work to be done.” Le sigh. This is actually the topic of the next Scrum Master forum meeting at my company – I’ll let you know where we land.



An easy one. So, where are you when you’re busy creating this Sprint Goal? You’re in your Sprint Planning meeting. That’s where.


Most importantly, Why set a Sprint Goal? Focus and Flexibility. The Scrum Guide puts it this way, ” It [The Sprint Goal] provides guidance to the Development Team on why it is building the Increment…The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.” It allows the Scrum Team to inspect and adapt throughout the Sprint to ensure that it’s working on the right stuff.

This is why during the Daily Scrum, the following 3 questions are asked:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

We tend to often trim the “meet the Sprint Goal” from the end of these. Let’s add it back 🙂


So now that we have a better understanding of the purpose and implementation of the Sprint Goal, I encourage us all (myself included) to put and keep this concept front of mind. I also urge us to revisit the Scrum Guide to (re)discover any hidden goodies – and share what you find!