TL; DR: Nine Sprint Goal Principles
In Scrum, the Sprint Goal serves as the spotlight that provides transparency to the Sprint Backlog, as the flag that allows the team to rally, and as the one thing that provides focus and cohesion. No Scrum team has ever been able to reap the benefits of the framework to the fullest extent without making the Sprint Goal a cornerstone of its efforts. The following nine Sprint Goal principles point at critical issues any Scrum team needs to consider on its path to excellence.
The Purpose of the Sprint Goal According to the Scrum Guide
The Scrum Guide characterizes the Sprint Goal as follows:
“The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility regarding the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.”
“The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.”
Source: Scrum Guide 2020.
The importance of the Sprint Goal for successful Scrum teams is evident as the Scrum Guide mentions the goal in multiple places all over the guide. For a complete list of all Sprint Goal-related quotes from the Scrum Guide in a format that is easy to understand, please refer to the Scrum Guide Reordered.
Nine Sprint Goal Principles to Support Your Scrum Team in Finding its Mojo
The following nine Sprint Goal principles will help your Scrum team navigate the tricky waters of Sprint Planning, supporting your team’s Sprint Goal creation:
1. Have a Sprint Goal in the first place: As a tactical framework, Scrum is good at scoring match points, delivering the maximum value to customers every single Sprint. For that purpose, agreeing as a team on a unifying goal is helpful as it serves as a beacon, allowing the Scrum team to focus on the tasks ahead. If your Scrum team does not or fails to create Sprint Goals, you are giving away an integral part of what makes Scrum successful in the first place.
2. Avoid the top-down Sprint Goal: The management or the Product Owner defines the Sprint Goal in advance to “help” the Scrum team on their challenging path. Of course, this is a flagrant violation of Scrum’s delicate system of checks & balances. The creation of the Sprint Goal is a collective effort of the Scrum team once the Product Owner explains the business objective of the upcoming Sprint.
3. Avoid output-driven Sprint Goals: The purpose of the Sprint Goal is to create an outcome: having an impact by changing the customers’ or users’ behavior. It is not about maximizing the output of tickets, story points, or person hours.
4. The pseudo-Sprint Goal: A random assortment of work items needs to be squeezed under a Sprint Goal; that is what Scrum is calling for, isn‘t it? about creating an outcome, see above, and not toiling on whatever work is thrown at the Scrum team; why don’t you stop fooling yourself? It is okay not to use Scrum if another way of working is tailored to your organization’s and team’s needs. We do not get paid to practice Scrum but solve our customers’ problems within the given constraints.
5. Have a reasonable forecast: Your Scrum team makes many interlinked assumptions about its future delivery capabilities that initially excite stakeholders only to disappoint them as you fail to deliver. Any Scrum team plays an infinite game, and there are no winners. Building rapport and trust with stakeholders requires more Wallstreet-like expectation management: stakeholders value a reliable delivery more than a sporadic outburst of productivity. Flatten the curve; there is life outside the Sprint bubble.
6. Don’t play safe all the time: Once bitten, twice shy. Despite all the lip service paid to agile principles, the organization does not take “underperformance” kindly. After all, the Developers’ commitment to the Sprint Goal means they promise to deliver every single work item from the Sprint Backlog, doesn’t it? That the deserving busting; Scrum is about accomplishing the Sprint Goal without regard to the output. The solution to this challenge is not to play safe on the side of the Scrum team but to address this organizational anti-pattern.
7. Avoid a confidential Sprint Goal: The Scrum team keeps the stakeholders in the dark until the Sprint Review, contributing to the black hole anxiety on their side. Cliff-hangers may be a popular way to keep the tension and excitement of the audience alive in several industries. However, in our business, transparency tops everything. Product Goals and Sprint Goals cannot be overcommunicated.
8. Have a “flexible” Sprint Goal: The primary contract between the Scrum team and its stakeholders goes as follows: Every Sprint, dear Product Owner, you have the opportunity to point the Scrum team in a different direction. In return, during the Sprint, we agree on not touching the current Sprint Goal to complete the required work. (Unless the Sprint Goal becomes obsolete, of course.) Therefore, to deal with life’s little surprises in a complex environment, our Sprint Goal always entertains some wiggle room. We are willing to renegotiate the scope if necessary while adhering to the Sprint Goal itself. Life is a continuous negotiation; why would Sprint be an exception?
9. Deliver the Sprint Goal more often than not: Bad luck happens, particularly in complex environments: Team members have unexpected absences, technology is not working as expected, management or governments intervene, and high-profile incidents deserve the Scrum team’s full attention—the list is endless. If this occasionally happens to your team, resulting in the non-delivery of your Sprint Goal, that’s okay. However, if your team constantly fails to deliver its Sprint Goals, your basic set-up is flawed. Maybe, a flow-based system would be a better way of working in your case?
For a good reason, the Sprint Goal is not optional in Scrum. The Sprint Goal is the spotlight that provides transparency to the Sprint Backlog, the flag that allows the team to rally, and the one thing that provides focus and cohesion. No Scrum team has ever been able to reap the benefits of the framework to the fullest extent without making the Sprint Goal a cornerstone of its efforts.
Does your Scrum team create meaningful Sprint Goals every single Sprint? If so, please share with us how they accomplish this feat in the comments.