Sprint goals are key to a successful Sprint. They help keep the Scrum team on track and moving together in one direction. Without Sprint goals, the Scrum team can easily lose focus and get sidetracked. In this blog post, we’ll discuss what sprint goals are and how they can help your Scrum team stay focused and achieve their objectives.

What is a Sprint Goal?

Sprint goals have been part of the Scrum framework for a very long time, but few teams truly appreciate the power of setting and using Sprint goals. Sprint goals are defined during Sprint Planning and help to

• Explain why the Sprint is important to the stakeholders and
• Guide the Scrum team throughout the Sprint.

For example, if your team was planning a Sprint to close out as many defects as possible before the ship date, the Sprint goal could be any one of the following:

• Maximize product quality before the ship date.
• Close all high severity and as many medium severity tickets as possible.
• Kill the bugs!

If your team was planning a Sprint to finish building a student registration capability for a university, your Sprint goal could be any of the following:

• Wrap-up registration workflow for the registrar.
• Finish online registration capability for the university students.
• Students should be able to do a complete registration by the end of the Sprint.

What’s really powerful about Sprint goals are how they work to keep the team focused from the moment they begin planning the Sprint all the way to the end of the Sprint. Sprint goals:

• Affect what gets loaded into the Sprint.
• Affect the solutions created during Sprint Planning.
• Are checked every day during the Daily Scrum to ensure the team is on track.
• Are the core behind certain decisions that can be made throughout the Sprint (more on this later).

Writing a Sprint Goal

The biggest challenge of Sprint goals is understanding how to write them. Thankfully, they really aren’t hard to do. Just follow these steps with your team and stakeholders during Sprint Planning:

1. I always recommend starting a Sprint goal with the phrase, “By the end of the Sprint,….” While unnecessary, this has the psychological effect of making the goal bounded by the end of the Sprint. Yes, everyone knows that the goal is to be accomplished by the end of the sprint, but there is real power in having it as part of the sentence itself.
2. Discuss what capabilities the stakeholders need to be able see by the end of the Sprint (even if it’s just a slice of a feature in order to get feedback). What is most important to them?
   • “I need to see the beginning of the student registration workflow.”
   • “I need customer names and email addresses (minimum) in the database.”
   • “Management needs some kind of report showing product activity.”
3. The Product Owner plays a role in this as well. What needs to be accomplished to move the product closer to the Product goal?
   • “I need students to be able to request being added to a class.”
   • “I need the registration function to collect useful metrics.”
   • “We must finish the ‘cancel class’ function.”
4. What about the Scrum team itself? What did they agree to do in the next Sprint during the previous Sprint Retrospective?
   • “We need more database skills.”
   • “We need to lower our work in progress to 3.”
   • “We need to improve our test scenario generation.”
5. As a group (everyone in the Sprint Planning event), combine the desires of the stakeholders, Product Owner, and the Scrum team into something the developers believe they can accomplish. Frequently, the earliest drafts of the Sprint goal are far too much for the Developers to accomplish during a single Sprint. The Sprint goal will be rewritten a few times until it becomes the developers can accomplish. The final decision for the Sprint goal is made by the Product Owner and the Developers. the final result might look like these:

By the end of the Sprint, we will create the first step in the student registration workflow and finish the feature to cancel a class; we will also reduce our work in progress to 3.

By the end of the Sprint, we will create the ability for management to see basic activity metrics on logins and session timeouts; we will also cross-train one developer on adding and modifying columns in the database.

Using the Sprint Goal

The Sprint goal is intended to help the Scrum team make decisions during the Sprint that improve the successful achievement of the Product goal (the ultimate deliverable for a Scrum team). The usefulness of the Sprint goal begins immediately after the goal is created.

Sprint Planning

Writing the Sprint goal is the first goal of Sprint Planning. The second goal is to load the Sprint with product backlog items that will help the team achieve the Sprint goal (yes, if you’re paying attention, that means the goal is to load product backlog items, not necessarily based on order in the product backlog, but on each item’s affect on achieving the Sprint goal).

Let’s use this Sprint goal from earlier:

By the end of the Sprint, we will create the first step in the student registration workflow and finish the feature to cancel a class; we will also reduce our work in progress to 3.

When discussing which product backlog items to include in the Sprint, the question that should be asked is, “will this item help us achieve any part of the Sprint goal?”

These items would likely be included in the Sprint:

• Collect basic demographic information (name, email, address) from the prospective student.
• When cancelling a class, ensure that all students currently enrolled are notified of the cancellation

These items would likely NOT be included in the Sprint:

• The registrar wants to be able to zero out a student’s balance.
• The student wants to remove themselves from a class before the first day of the semester.

Why? Because they don’t help the team achieve the Sprint goal. It’s not that they aren’t important; it’s that they aren’t part of the current Sprint’s goal.

What About Business As Usual Stuff?

Yes, all Scrum teams have business-as-usual-type work they are always doing, like:

• Responding to defects reports
• Little corrections and enhancements

Can these be added to the Sprint too? YES, however, the more business-as-usual you add to the Sprint, the less new functionality gets done. At some point, the business-as-usual work overwhelms the team and little to no product value is created.

Let’s be honest. If your team has so much business-as-usual work to do that they can’t build product value, your problem isn’t about what gets loaded into the Sprint. The problem is either that the team’s purpose is overwhelming the team OR the team is doing a poor job of building high quality functionality. Either way, it’s time to re-evaluate the team.

Daily Scrums

The Scrum team should review their sprint goal every day during the Daily Scrum. This will help ensure that they are on track to achieve their goal and identify any potential obstacles that may need to be addressed. By regularly reviewing and adjusting their sprint goals, the Scrum team can stay focused on what is important and ensure that they are making progress towards their overall objectives.

For example, let’s use the Sprint goal from earlier:

By the end of the Sprint, we will create the first step in the student registration workflow and finish the feature to cancel a class; we will also reduce our work in progress to 3.

During a daily Scrum, your developers should share what they are working on and then discuss if they are likely to meet the Sprint goal.

Really important point: “meet[ing] the Sprint goal” IS NOT about completing the tasks in the Sprint Backlog. The tasks in the Sprint Backlog are part of the Sprint plan and, as such, are WRONG. The goal is paramount…the tasks are merely a forecast based on what the team knew when they created them.

For example, let’s suppose, during the daily Scrum, the developers ask, is our work in progress 3 or less. They discover that there are 4 product backlog items in progress at the same time. What do they do? They agree to stop work on one of the items and get the developers working on the fourth item to help the developers working on the other 3.

As another example, let’s suppose the developers are concerned that the first step in the student registration workflow isn’t going well and might not be completed by the end of the Sprint. What are their options? They could

1. Go back to the product owner to clarify and perhaps negotiate what exactly is intended in “the first step in the student registration workflow.”
2. Reassign tasks to get the best developers on the critical ones.
3. Identify a different solution that would allow the work to get done more quickly (but with the same high quality).

The developers should keep the Sprint on track to the Sprint goal as best they can, even if they aren’t successful.

Failing to Achieve The Sprint Goal

Uh oh! The Sprint ended and the developers didn’t achieve the Sprint goal. what now? If your organization is like many others, no one will even notice.

Nope. Most organizations are uselessly obsessed by “velocity.” In other words, most organizations are more concerned with “how much work” the team got done instead of “how much value” the team was able to produce.

Here’s a clue as to why an unhealthy obsession with velocity is a bad idea:

Scrum teams that can produce four times as much garbage today than they could last year are still producing garbage.

So what SHOULD happen if your Scrum team doesn’t achieve the Sprint goal?

During the Sprint Review, nothing. The Sprint Review isn’t about the Sprint goal, it’s about the Product goal.

During the Sprint Retrospective, the developers should discuss why they didn’t achieve the Sprint goal. It will likely be result of one of the following:

1. The Sprint goal was set too aggressively (too high)
2. Unexpected defects in the current increment (the current product) made it harder for the developers to get things done
3. Unexpected delays (getting answers to questions, getting approvals to proceed, getting needed resources) occurred during the Sprint
4. The developers lacked enough of one or more key skills.

None of these are reasons to punish your developers or have some useless critique of their performance end up on the annual performance evaluation. Instead, they are really important issues to discuss and solve during the Sprint Retrospective.

1. How can we better set a reasonable Sprint goal in the next Sprint?
2. What do we need to do to improve product quality?
3. How can we get answers to our questions more quickly?
4. What skills do we need to improve?

Conclusion

If you’re looking to improve your ability to achieve Product goals and your Scrum team’s performance, start by helping them learn to set clear and achievable sprint goals. Sprint goals will help keep your Scrum team focused and on track. They are the key to a well-executed Sprint. Thanks for reading! We hope this was helpful. If you have any questions, please feel free to reach out to us. We’re always happy to help!