A Sprint Goal provides a focused objective for the team to produce an increment of software. It consists of a short description of a business or technical outcome that the team plans to achieve during the sprint, for example “Implement basic user profile entry (CRUD: create, read, update and delete)”.

Each sprint should be given a unique goal stating why the increment is worthwhile; this acts to align the team whilst planning, during the sprint and at the review.

Benefits of a Sprint Goal

The advantage to having a sprint goal is that it helps with –

• Prioritisation – A goal supports the ordering of product backlog items when selecting content for a sprint. The Product Owner should select the initial goal for the sprint and then select stories to support that goal. Note that during sprint planning the scrum team may agree to change the sprint goal to reflect the work finally selected. Within the sprint the goal also becomes vital for the team when they are deciding ordering for tasks.
• Focus – As well as providing a basis for the sprint planning session the goal provides a reason and shared objective for the increment to guide the team and enable commitment. The target is then for the team to accomplish the sprint goal and not just to complete the list of selected stories.
• Feedback – Having a goal makes it easier to identify relevant users to review the increment and to receive quicker focused feedback. Analysing the feedback against a single goal is also easier than multiple disparate comments raised against several different stories.
• Communication – Speaking to stakeholders and other agents outside of the team is easier when discussing what a sprint is for and helping them to decide if they should be attending the sprint review.

Creating a Sprint Goal

The product owner and development team agree the goal collaboratively in part one of sprint planning and like all targets it must be SMART:

• Specific – The goal needsto be clear and unambiguousrather than generic. For a specific goal the team must agree on what is important, why is it needed, whois required, where it’s going to happen and which elementsare required, thiscan be summarised as the five ‘W’ questions:
  • What needs to be accomplished?
  • Why is it required?
  • Who is involved?
  • Where it is to be done?
  • Which product backlog items are needed?
• Measurable – The goal needs progress to be quantifiable, whether this is by seeing progress by the number of stories completed or by associated acceptance tests.
• Attainable – It must be realistic for the team to be able to accomplish the goal within the sprint considering all other factors. A stretch goal by a high-performing team is fine if they decide to write it but, as always, it is the team that decides to accept the goal or not.
• Relevant – The goal must address a challenge upon the project and move the team closer to the release or overall vision. Early sprints often focus on the reduction of risks and uncertainty (learning), later sprints generally focus on delivering customer features (delivery).
• Time-bound – The goal must be achievable within this sprint.

Visualisation

The goal should be displayed prominently on the task board during the sprint so that the team can reflect on it at each daily scrum.

During the daily scrum the team answer three questions that reinforce the goal and work to re-align the team each day:

• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Roman Pichler shows an image including the sprint goal displayed on the task board in his excellent post on effective sprint goals:

Failing to Meet the Sprint Goal

If the goal is rendered obsolete then the product owner should cancel the sprint, this is understandably rare. Sprint goals can be missed by teams due to many reasons – insufficient understanding, over-committing, discovery of technical debt, resource reduction etc. Missing a sprint goal is an essential item to be raised during the sprint retrospective to find the underlying reason.

Accomplishing the Sprint Goal

Good work, the sprint goal has been demonstrated in the review and accepted. Another successful sprint chalked up, onto the retrospective and then straight into planning the next sprint.

Meeting the Spring Goal Early

Reality annoyingly does not always reflect estimates so sometimes a team will accomplish the sprint goal early, does this mean an early trip to the pub? Unfortunately not, the Scrum Guide states that the development team must collaborate with the Product Owner upon the scope of the Sprint backlog, this enables additional product backlog items to be pulled into the sprint.

Conclusion

The Sprint Goal is a great device utilised by Scrum Teams to add cohesiveness to each cycle of development. High-performance Scrum teams probably no longer need this uniting target and good luck to them, this blog is called Pragmatic Scrum for a reason so for now I will still be using a Sprint Goal.