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.

We’ve all experienced this. Your team seems to be working hard. In fact, you know your team is working hard because you’re right there in the trenches with them. But, no matter how hard your team works, they never seem to actually get anything finished.

If this sounds familiar, then you’re not alone. Most teams face this problem at some point in their development. However, despite how common this problem is it’s actually quite easy to overcome.

Why It Happens

To overcome this problem you first have to understand why it happens, in the first place. Most often this is due to two reasons.

First, it can happen because your team is accepting work from outside of the Sprint. This is the “can’t wait” work that wasn’t planned for during your team’s Sprint Planning, but reared it’s head after the Sprint has begun. Sometimes this happens because the Scrum Master is unable to head off a major stakeholder. Or sometimes the Scrum Master simply can't make that stakeholder understand the impact that this new work will have on the team’s outcome. Or even other times, the Scrum Master may not even be aware of the unplanned work, in the first place.

But regardless of the reason, if your team is spending time working on unplanned work instead of the work they had planned for the Sprint, then they may look busy but they’re unlikely to finish what you expect them to.

Second, it can happen because your team is working on too much work at once. This can be counter-intuitive at first, but if your team decides to tackle all of their work at once then the team will make surprisingly little progress on any of their work. This is because the team’s total effort will be spread across a much wider surface area resulting the in team making very little forward progress.

In addition, on many teams when the amount of work in progress is not closely tracked, it can be common for some individuals to begin work on one item and then move to a second item before the first item is complete. Once again, this can create an image of very busy individuals on a team, but with very little actual work in result.

Luckily, there are solutions for both of these situations that will get your team back on track and back to finishing the amount of work that you know they’re capable of.

Make It Visible

In the first case, where the team is continuing to work on items outside of the Sprint, work with your team to craft a clearly defined Sprint Goal that describes the goal that the team should accomplish with the work in the next Sprint. Once your team is in agreement about the goal, share the goal with your stakeholders so that everyone understands what your team plans to accomplish during the next Sprint and how this Sprint Goal contributes to your overall product goals. Then, when outside work begins to appear during the Sprint, you can work with your stakeholders to evaluate how that work maps to the goal the team has selected for the Sprint and what effect accepting the work may have on that goal.

If you’re still unable to prevent the work from being worked on during the Sprint, then make a special effort to estimate the newly accepted work and add it the Sprint board. You can even dedicate a reserved row of the Sprint board for this type of work, or use a different colored card so the unplanned work is immediately obvious. This visual differentiation will make visible the impact that the unplanned work is having on the work that was originally planned in pursuit of the Sprint Goal. In addition, the estimated points will allow you to better communicate to your stakeholders during the Sprint Review what percent of the team’s effort was spent on work that didn’t directly contribute to the Sprint Goal.

Both of these actions will help your stakeholders stop thinking of the Sprint as an empty bucket that work can simply be poured into, and instead begin to think of the Sprint as a strategically planned batch of work that moves the team closer to a stated goal.

Limit Your Throughput

In the second case, where the team is working on too much work at once, work with your team to establish work in progress limits, commonly known as WIP limits, on the key states of your Sprint board.

A WIP limit restricts the number of items that can be in a given state at any time. For example, in the image below, a WIP limit of 3 has been assigned to the Development column and a WIP limit of 2 has been assigned to the Testing column. This means that at any given time, no more than 3 items can be in development at one time and no more than 2 items can be in test at one time.

What happens if the WIP limit is reached? Then your team must work together to figure out how to complete the items in the column where the limit has been reached to make room for new work, thus allowing more work to flow through the process.

For example, imagine that a developer on your team completes the an item and attempts to move it to the Testing column. However, the Testing column has already reached its limit. The developer must work with your team’s testers to understand how they can help clear the existing the items from the Testing column. This may mean that the developer needs to assist the tester with their work so they can complete the items currently waiting to be tested, or that that team as a whole needs to make a greater investment into automated testing so that the testing process is more efficient overall. Regardless of the solution, the new item cannot be added to the Testing column until the existing items have been cleared.

While at first, WIP limits may seem as if they would cause a team to move slower, the opposite is actually true. WIP limits incentive your team to move work to completion, rather than to simply start it. This results in more work being completed by your team which allows them to reach their goals faster.

Focus on Finishing

Many teams look busy but surprisingly few actually complete the amount of work that may be expected of them. But, by defining clear goals for each Sprint that your team can aim for, and then incentivizing them to focus on finishing the work required to complete those goals, you can ensure that your team actually delivers the value that your stakeholders expect.

Do you want to learn more about how you can help your team deliver work more efficiently? Check out my course series, Using the Scrum Framework, to learn how you can help your team reach their highest potential and deliver a great product to market.

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