28days until

Sprint Goal

… you are ready to embark on a Sprint, and you are planning it in a Sprint Planning Meeting.

✥      ✥      ✥

The objective of a Sprint is to deliver value to the stakeholders. However, simply following a list of tasks (e.g. SBIs)  does not necessarily result in the creation of the greatest value possible.

A common occurrence is that partway through a Sprint, it becomes clear that the team will not complete every SBI in the Sprint Backlog. This is often due to the emergence of work required to complete SBIs. You still want to deliver something of value if at all possible, which implies re-planning the work for the Sprint. But an emergency re-plan requires forethought and time. A study performed by Carnegie-Mellon University reports that teams that prepare ahead of time for interrupts handle them 14% better than teams that don't prepare. Teams that prepare for interrupts complete an uninterrupted task interval 43% faster than teams that don’t prepare. It’s a mindset to prepare for bad things: when they happen, the teams can pivot to a new configuration to handle them, without external coaching.

Another scenario is that important technical knowledge about certain Product Backlog Items (PBIs) becomes critical to sufficiently specify them. A technical prototype is needed in order to validate a proposed architecture or learn performance characteristics of a technology. While such work should be identified in a PBI,  its uncertain nature requires focus on the knowledge to be obtained. 

In some cases, the greatest value might not be an explicit Product Backlog Item.  To give one example, the greatest value for the team was to increase revenue per Scrum Point, and the team devoted a Sprint to this effort. On the other hand, sometimes the buik of the Sprint's value derives from one critical PBI out of many.


Create a short statement of the value that the team intends to create during the Sprint. This becomes the focus of all work in the Sprint.

The entire Scrum Team jointly creates the Sprint Goal. The Product Owner should have the best view of value, and thus will naturally guide the creation of the Sprint Goal.

✥      ✥      ✥

The Sprint Goal often equates to the contents of the Sprint Backlog, in which case all Sprint Backlog Items contribute to the Sprint Goal. If the Sprint Backlog is completed, the Team will accomplish the Sprint Goal. But it is sometimes possible to complete the Sprint Goal (in some way) without completing all SBIs. This helps teams handle contingencies: If emergent impediments threaten the Team's delivery of the Sprint Backlog, the Team automatically resorts to the Sprint Goal as "Plan B" without expending long hours re-planning. So examples of the Sprint Goal include:

  • Delivering a specific PBI this Sprint
  • No overtime this Sprint
  • Increasing our velocity by 15% this Sprint

The Sprint Goal should be visible to the team; for example, put it on the Scrum Board.

The Sprint Goal frames the selection of PBIs for the Sprint but in some sense the Sprint Goal is more important than the individual PBIs.

Since the Sprint Goal is the chief aim of the Team,  it is theoretically possible to repeatedly achieve the Sprint Goal while completing only a fraction of the SBIs each Sprint. This should be uncommon, because the SBIs should align with the Sprint Goal; if not, there is a serious problem with the Value Stream. Second, the team’s Velocity is still calculated using the completed PBIs.

Velocity helps teams understand if they doing things right (with the assumption that doing things right increases your velocity.) The Sprint Goal helps teams ensure that they are doing the right things. It is about understanding the Why of what the team is doing, so that they can keep focus on it when things change.

Autonomous Teams states that team members must be able to manage themselves to accomplish their goals, and Developer-Ordered Work Plan states that development teams must be free to order their work however they see fit. The Sprint Goal gives the Product Owner the opportunity to influence how team members works – they should manage themselves and order their work in order to accomplish the Sprint Goal.

Jeff Sutherland adds that in addition to keeping the team focused it encourages Swarming: Can we get everyone working on one thing together? He relates:

In Silicon Valley in 2007, Palm was working on a Web OS which was later acquired by Hewlett-Packard. Sprint to sprint the teams were doing well until they appeared to hit a wall in a couple of Sprints. PBIs were not getting finished. Developers were demotivated and going home early. I was brought in and got the Product Owners and ScrumMasters to spend an hour interviewing team members on why they were demotivated. We found that they did not understand the reason the were working hard on low level PBIs.

We spent an afternoon cleaning up the Product Backlog showing a clear linkage between high level stories and the decomposition hierarchy. As soon as the developers understood that the Sprint Goal was to improve performance of the Web OS by 10%, they were motivated to complete the low level stories and velocity went back up to normal.

Understanding why the PBIs are being implemented is critical for developers, particularly for expert developers who would prefer to go surfing if they don't see the reason for their work.

The study at Carnegie-Mellon was designed by NBC journalist Bob Hudson and author Hugh Thompson in collaboration with IT professor Alessandro Acquisti and psychologist Eyal Peer, and appeared as "Brain Interrupted" in the New York Times, 5 May, 2013, page SR12. The quip from Jeff Sutherland is from a personal conversation between Jeff, Neil Harrison and Jim Coplien on 4 August 2013.