Here's how the Scrum Guide defines it:
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.
(In this context, the "Increment" means whatever the software or system is that you are working on. Your deliverable, in other words.)
The Sprint goal is typically a short, one-sentence description of what the Scrum Team plans to achieve during the sprint. There are other formats you can use for your Sprint Goal, but a sentence is good enough to start with. Think of the Sprint Goal as a kind of mission statement that will guide the team over the next two weeks of the sprint.
Suppose you step into the elevator and find yourself face-to-face with a senior executive. "So, what's your team working towards this sprint?" says the executive. You have ten seconds to finish your answer before the two of you reach your floor. What do you say? Whatever you do say—assuming that it's coherent, true, to-the-point, and clarifies what is special about this sprint—is probably your Sprint Goal.
The Sprint Goal has many important functions within the Scrum Team:
It's fine for your team to change the content of the Sprint Backlog as you progress through the sprint. Your team can drop items, add items, change the scope of items—whatever you like... as long as those changes don't endanger the Sprint Goal. That's the bargain when we start the sprint: the Sprint Backlog is flexible, but the Sprint Goal is not.
It's impossible to know how well you are doing if you don't know what you are trying to accomplish. The Sprint Goal gives your team a concrete objective to measure your performance against. No matter what happens during the sprint, the question "How close are you to meeting your Sprint Goal?" is always key.
Suppose things go totally pear-shaped during a sprint, and it's clear to everyone that the Sprint Goal can't be achieved by the team in the sprint. In that case, we deploy a rarely-used feature of Scrum: canceling a sprint. When the Product Owner cancels a sprint,
It's very rare that circumstances changes so much that you need to cancel a sprint, but sometimes it would be a waste of time for the team to keep working towards their original sprint plan. In those cases, having a Sprint Goal makes it easier to determine when this is one of those rare cases when the team should invest the time in re-planning their sprint.
It's not very inspiring when a team pulls in ten random to-do items each sprint. That leads to team members grabbing one item apiece and going off to work in isolation from each other.
As opposed to what? If the team instead focuses on a common Sprint Goal that is obviously important and can't be completed by any of the team members working alone, then the team will tend to pull together rather than pull apart. That collaboration among team members unlocks learning opportunities and development potential that would otherwise go untapped.
Did you know that the daily standup meeting is all about your Sprint Goal? It's true. Here's the questions that the Scrum Guide uses as an example for how you can run your daily standup:
Some people tend to talk about irrelevant topics during the daily standup meeting (e.g. "I had a dentist appointment. I checked my e-mail. I attended the all-hands meeting."). The example questions listed above are laser-focused on the purpose of the sprint. (What's the purpose of the sprint? Achieving the Sprint Goal.) They make it crystal clear when someone's answers have wandered away from what the daily standup meeting is trying to achieve.
Try working with your team to create a meaningful, concise Sprint Goal during Sprint Planning for your next few sprints, a goal that's something more specific and inspiring than "Complete all the items in the sprint backlog."
← home