This post originally appeared on the PivotalTracker blog.

Let’s try an experiment. Open your Sprint Backlog and take a look at the stories that are slated for your current Sprint. Do you see a theme that ties each of them together?

Too often, the set of stories that teams select for their Sprint has no overarching theme or focus. In fact, while these stories may be individually valuable, at times their selection can appear almost random.

But high-performing agile teams begin each Sprint Planning session by defining an overarching goal that they would like to accomplish by the end of that Sprint. This shared planning helps the team select a cohesive set of stories that will help them reach that goal. However, there’s also another advantage to crafting a great Sprint goal.

A great Sprint goal helps your team understand *why* it’s embarking on the Sprint in the first place. This context not only better positions your team members make more informed decisions during the sprint, but it also gives them guidance in the event that they need to adjust their Sprint plan during the Sprint to react to unexpected developments.

How Are Great Sprint Goals Crafted?

Crafting great Sprint goals is easier than you may think. The best time to craft your Sprint goal is at the beginning of each Sprint Planning session. Doing this at the outset will help set the context for what the team will be tackling over the next Sprint and better equip your team to select the stories that will support that goal. While the process of crafting a sprint goal is typically led by the Product Owner, ideally the entire team should be involved in this process. This will create a shared understanding of the goal that the team is trying to accomplish and create buy-in towards that goal.

When crafting your Sprint goal, remember that the best goals are specific enough that there will be no ambiguity as to whether or not the team accomplished the goal, but also are not so specific as to constrain the team’s flexibility to adapt their Sprint plan in pursuit of deciding how to best achieve that goal.

For example, *Increase the number of social login options available to the user* is a great example of a Sprint goal, since it defines a clear direction but leaves the flexibility to the team to decide how to best achieve that goal.

As another example, while *Improve the long-term maintainability of the reporting framework* is a great Sprint goal, *Reduce technical debt* is not. This is because while the former gives the team a clearly defined and high-level objective to aim at, the latter is vague and tough to quantify. This can make it hard for the team to clearly decide at the end of the Sprint whether or not they actually achieved their goal.

Planning From the Top Down

So where do Sprint goals come from, you ask?

When first creating a Sprint goal, many teams are tempted to just select stories as usual during their Sprint Planning session and then simply derive a Sprint goal from any common themes they spot in those stories.

While at first, this approach may seem better, it often leads to vague Sprint goals that merely describe the lowest common denominator found in every story selected for that Sprint. As a result, it can be hard to quantify whether these goals were achieved at the completion of the Sprint or even whether completing the goal actually yielded any value to the organization and the overarching release.

The best Sprint goals are often derived from your overarching release goals. Specifically, if you’ve defined a high-level goal for your release, you can begin by decomposing that goal into roughly Sprint-sized chunks, of which each chunk will become the starting point for a Sprint goal. Don’t worry if you’re not sure how to decompose your high-level goal into Sprint-sized chunks as this is a great opportunity to involve your technical team early so they can help you understand how large each chunk of work is likely to be. Not only will this increase the likelihood that your initial chunks of work fit together well, but the early involvement of your team will also help to create a shared understanding of what the goals of the release are, as a whole.

Seeing the Bigger Picture

Crafting clear Sprint goals helps your team understand how the work they are doing in each Sprint is a part of something bigger. Helping your team see the bigger picture not only equips them to make better-informed technical decisions during the Sprint, but it also gives them valuable insight into the overall vision for their product as well as how the work they are doing today contributes to that vision.

Curious to try this for yourself? Invite your team to collaborate with you during your next Sprint Planning meeting to set a Sprint goal that moves your team closer to success. Then, after the end of that Sprint, let us know in the comments below how it went! I’d love to hear how this worked for you and your team!

Want to learn how to deliver the work that matters most to your users? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Scrum Master or Product Owner and to help your team reach their highest potential.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.