Why should you have a Sprint Goal?

When you look into the “average day” of a Development Team member, you will notice far too often that a lot of his or her time is spent on Sprint-unrelated tasks. This doesn’t mean that he or she is doing unnecessary or unimportant tasks. It’s more like that person - or the team as a whole - doesn’t share the perspective on what the actual goal is that the Development Team is trying to achieve.

Let’s take a look at two important aspects regarding this subject.

Guidance for the Development Team

A Development Team is usually very much able to create great features that would do great in the - for example - software application that they are building. Every team member has it’s own perspective and view of the perfect solution and would really like to contribute to that.

In order to achieve the best results as a team, it’s important to have a shared understanding of why certain features are built. This can be achieved by trying to fit the wanted outcome of each sprint into a “Sprint Goal”. The Sprint Goal is usually a term or short sentence describing a feature or piece of functionality.

Sprint Planning

While it’s easy to gather a bunch of Backlog Items to work on in a Sprint, it’s a little harder (but much more valuable) to have a set of Backlog Items that fit together and in this way, provide more business value.

For example, for the following Product Backlog Items which pass during the Sprint Planning session:

  • Adjusting e-mail preferences;
  • Provide a profile picture;
  • Change a profile picture;
  • Delete account. 

A sprint goal of “Profile Management” would fit this set of items, providing the whole team with a shared perspective on what to do in the current Sprint. However if one of the following Backlog Items pass during discussions, it’s easy to argue that they don’t fit into the current Sprint:

  • A shopping cart which users can use to store products before paying;
  • A user being able to log in to the web application;
  • Users should be able to share their findings on our platform easily.

For this reason it’s important to see which stories fit together, in order to maintain focussed during the Sprint… speaking of which, let’s dig into “Focus” next!


It makes sense that if you focus on the tasks that are required to meet your goal, that you are more likely to succeed than when you’re spending your time on unrelated tasks (to the goal, that is). But why are team members spending time on other tasks? This is mostly related to external factors providing new work… like someone from the maintenance team mentioning a recent incident that “certainly has priority” above some of the Sprint tasks.

Let’s look into an example: If an end user is unable to use the “Provide feedback” button on the Production Environment, that would usually be an incident which has a higher priority than a developer building a new button which would allow a user to change his profile picture via the web interface. But if, at the beginning of the Sprint, the Scrum Team has decided that “Profile Management” was the Sprint Goal, it’s easy to determine that:

  • Fixing a “Provide Feedback” doesn’t help at all to achieve the Sprint Goal


  • Creating a button to change a profile picture contributes to the Sprint Goal

This doesn’t mean that the developer should ignore the maintenance team colleague, but it does mean that this developer should speak up to him or her and say: “I’m sorry, my current focus is our Sprint Goal which our team has determined at the beginning of the sprint. If you believe that your task has priority, please step up to our Product Owner and Scrum Master so they can look into this and determine the best course of action.”.

Hence focus is one main advantage of having a Sprint Goal, it prevents ad-hoc tasks from entering the task-list of a Development Team member.

Wrapping up

You should use a Sprint Goal because...

  • Sprint Goals help the Scrum Team to deliver value every Sprint;
  • Sprint Goals help the Development Team to stay focussed;
  • Sprint Goals help the Product Owner to determine priority;

Feel free to share your own great ideas so we can all improve our Agile way of working by learning from each other.

naar overzicht

Wilt u reageren of meer weten?

Heeft u iets in dit artikel gelezen dat uw interesse gewekt heeft? Laat het ons weten!

Deze post delen?

Trotse winnaar van een
FD Gazellen Award
2014 t/m 2018

© 2019 | Europalaan 12a | 5232BC 's-Hertogenbosch | T: +31 (0)85 0290550 | E: info@pancompany.com