In this blog post I explain why the Sprint Goal is key for an effective implementation of Scrum and how it is widely present in the Scrum framework by exploring its “lifecycle”.
Scrum is defined as a framework to address complex problems while delivering products of the highest possible value. A good Sprint Goal is, then, the one focusing to validate value assumptions to help achieving what Scrum is meant for (maximizing the value of the product iteratively and incrementally).
When we talk about value we look at the Product Owner as a value maximizer and the way he is managing the Product Backlog. A (business) value starts with a clear product vision. The Product Owner narrates the product vision throughout the Product Backlog. He orders the Product Backlog Items (PBIs) to best achieve goals.
A complementary practice to do so, is to combine “impact mapping” and “story mapping” so that business objectives are related to their coherent PBIs. Business objectives are steps toward maximizing the product value.
Those business objectives are actually Sprint Goals candidates. During the Sprint Planning, the Product Owner discusses the (business) objective that the Sprint should achieve and the related PBIs. The Dev Team decides on the number of items to be selected from the Product Backlog to forecast the functionality it could achieve during the next Sprint. The Scrum Team then crafts the Sprint Goal as an objective that will be met within the Sprint through the implementation of the Product Backlog. The Sprint Goal arising from a business objective is a way to validate value assumptions.
During the Sprint, the Dev Team keeps in mind the Sprint Goal. No changes are made that would endanger the Sprint Goal. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog. The Dev Team focuses on delivering a Done Increment, no later then by the end of the Sprint, that achieves the Sprint Goal.
The Dev Team uses the Daily Scrum to inspect the progress toward the Sprint Goal. They update their Sprint Backlog as more is learned on how to best achieve the Sprint Goal. It actually gives them flexibility and foster self-organization on how to create the Increment with the expected quality goal. The Sprint Backlog becomes, then, a flexible plan to deliver a Done Product Increment that best achieves the Sprint Goal. The Product Increment is actually a tangible implementation of the Sprint Goal, a tangible way to validate the value assumption.
The Sprint Goal, when it becomes obsolete, would cause the cancellation of the Sprint. The value creation is no longer relevant. The Scrum Team has the courage to not waste efforts and the ethic to not deliver useless features to end users.
At the Sprint Review, the Scrum Team and the stakeholders inspect progress toward the Sprint Goal by inspecting the Product Increment. The Product Increment must be in a usable state so that the Product Owner can validate the value assumption by releasing it to the market and exposing it to real users to gather feedback. An Increment that achieves the Sprint Goal is a step toward a goal.
A "Done" (transparent) Increment supports empiricism. It enables predictability by validating (inspect & adapt) the value assumption expressed via the Sprint Goal. This is the core of Scrum!
The Sprint Goal helps the stakeholders understand what would be valuable for the product. The Scrum Team and the stakeholders collaborate on the next valuable items to optimize the value of the product. They actually collaborate on the subsequent business objective to be validated during the next Sprint. They are shaping the next Sprint Goal candidate.
At the Sprint Retrospective, the Scrum Team inspects how they collaborated during the previous Sprint to achieve the Sprint Goal and adapts their Definition of Done to increase the quality of the product. Adding stringent criteria to their DoD will result in a higher quality implementation of the Sprint Goal into a Done Product Increment, during the upcoming Sprints.
As a closing to this blog post, let’s recap the Sprint Goal “lifecycle” to explore how it is widely present in the Scrum framework:
- Emerging from the Product Backlog as a business objective expressed by the Product Owner as a value assumption,
- Created at the Sprint Planning by the collaborative work of the Scrum Team,
- Going through the Sprint to be implemented into a Done Product Increment by the Development Team as a tangible way to validate the value assumption,
- Helping the stakeholders in knowing what value will be delivered and having an interest in attending the Sprint Review,
- Inspected, ultimately, during the Sprint Review, by the Scrum Team and stakeholders, to validate the value assumption,
- During the Sprint Retrospective, improving ways to better implementing it into a Done Increment with higher quality in future Sprints,
- Going back to the Product Backlog as a subsequent business objective (Sprint Goal candidate) resulting from the inspection & adaptation done by the Scrum Team and stakeholders.