…you are ready to embark on a Sprint, and you are planning it in Sprint Planning.
The objective of a Sprint is to deliver value to the stakeholders. However, simply following a list of Sprint Backlog Items (SBIs; e.g., tasks) does not necessarily result in the creation of the greatest value possible.
Because the team lays out its work plan in terms of individual tasks or deliverables, it’s easy for it to pick up an individual item and work on the item in isolation during the Production Episode. However, that dilutes the innovation that comes from the interactions between individuals who bring different perspectives to the work. Cubicle walls can become barriers to continuously communicating insights that are important to not only one developer, but rather to many developers (Development Team members) or to the entire team. Teamwork suffers.
The team may need to partially replan a Sprint in progress to ensure that the team delivers value to the stakeholders at the Sprint’s end. New work may emerge from the team’s latest insights, and the team should update its plan accordingly. If the team would instead follow the original work plan, it might not create the greatest value possible.
Another common occurrence is that partway through the Sprint, it becomes clear that the team will not complete every SBI in the Sprint Backlog. This is often because the work required to complete SBIs expands. The team still wants to deliver value if at all possible, and it may take replanning to do so. Replanning the work for the Sprint requires forethought and time.
Another scenario is that the team needs important technical knowledge about how to implement a Product Backlog Item (PBI) to know how to develop it with confidence.
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 Sprint, and the team devoted a Product Backlog Item to this effort. On the other hand, sometimes the bulk of the Sprint’s value derives largely from one critical PBI out of many.
Therefore:
The Scrum Team commits to a short statement of the value it 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 will naturally guide the creation of the Sprint Goal because he or she has the best view on the next step toward the Product Vision and on how to create the Greatest Value.
- The Scrum Team should commit to the Sprint Goal as something always within reach.
- The Development Team creates one Regular Product Increment to meet the Sprint Goal of each Sprint.
- The Scrum Team can use the Sprint Goal to frame the selection of PBIs for the Sprint but in some sense the Sprint Goal is more important even than the sum of the individual PBIs.
- The Sprint Goal creates coherence in the PBIs, helping to create a valuable Product Increment.
- One good initial approach to a Product Backlog is to express it as a list of Sprint Goals, which the Product Owner and Development Team together elaborate into PBIs.
The Sprint Goal is the sole mechanism by which the Product Owner can influence the potential order in which the Development Team carries out its work (by inferring urgency from the importance conveyed by the Sprint Goal)—but, again, only with the Developers’ consent.
If the Development Team concludes that they cannot accomplish the Sprint Goal, it should refine the Sprint Goal with the Product Owner.
The Development Team commits to the Sprint Goal. This Sprint Goal can help unify the Development Team (Unity of Purpose), and it serves to build stakeholders’ trust in the team.
The Sprint Goal should be visible to the team; for example, put it on the Scrum Board or other Information Radiator.
The Sprint Goal usually relates to product value. The team can alternatively define Sprint Goals in terms of process goals—for example, doing all programming through pair programming, or showing up on time for the Daily Scrum every day.
Repeatedly driving to the Sprint Goal motivates the team to a higher level of engagement; conversely, the Happiness Metric can be an effective tool to define or suggest Sprint Goals.
