✥ ✥ ✥
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.
✥ ✥ ✥
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:
The Sprint Goal should be visible to the team; for example, put it on the Scrum Board.
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:
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.