No Sprint Goal, No Cohesion, No Collaboration

There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. For example, what if there is no Sprint Goal — Sprint after Sprint? What if the Scrum team is always only working on a random assortment of work items that seem to be the most pressing at the moment of the Sprint Planning?

Join me and delve into the importance of the Sprint Goal for meaningful work as a Scrum team in less than two minutes.

The Purpose of the Sprint Goal According to the Scrum Guide

According to the Scrum Guide, the Sprint Goal serves the following purpose:

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of 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 Sprint Goal is many things to the Scrum team: a beacon showing how to create more value for customers and the organization, a rallying cry to collaborate as a team, and a measure to figure out whether the Sprint was successful. 

Successfully identifying the Sprint Goal is thus a mission-critical step for every Scrum team. The Sprint Goal turns a Sprint into a team endeavor founded on cohesion, collaboration, and self-management. Anything less is merely toiling on an “assembly line,” probably leading to becoming a feature factory.

Reasons for Having No Sprint Goal

In my experience, there are three main reasons why a Scrum team is not capable of creating a Sprint Goal during the Sprint Planning:

• Focusing on getting the most pressing work done: The Product Owner proposes a direction that resembles a random assortment of tasks, providing no cohesion: “We need to work on 123, 426, 637, 845, and 343.” (Probably, the Scrum team does not have a Product Goal; it is all about business-as-usual and keeping the ship afloat. On the other hand, maybe, the product is in such bad shape that it is all about fire-fighting. Whatever the reason, these use-cases are less suited for Scrum as product discovery and delivery framework.)
• Last minute Product Backlog: The Product Owner and the rest of the Scrum team do not invest adequately in Product Backlog creation and refinement. Consequently, they rush to fill the Product Backlog immediately before the Sprint Planning to ensure there is enough work for the upcoming Sprint. (Garbage in, garbage out. This approach points to a fundamental misunderstanding or ignorance regarding the purpose of Scrum: when to use it, and what Scrum’s critical success factors creating value for everyone involved are.)
• Someone imposes a Sprint Goal: The Scrum team does not collectively decide on the Sprint Goal, but an individual imposes their idea of a Sprint Goal upon the team; for example, an outside stakeholder. (This may be an edge case. However, it is equally defying Scrum’s first principles, as Scrum is a framework based on the pull, not the push. The Scrum team is not an internal agency but a self-managing entity tasked with solving customer problems.)

The Consequences: If not identifying a Sprint Goal is the natural way of finishing your Sprint Planning, you probably have never embraced Scrum as a framework in the first place. Or, you have outlived the usefulness of Scrum as a product development framework. In the latter case, depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak Product Owner who listens too much to stakeholders instead of aiming to accomplish the Product Goal, composing and ordering the Product Backlog appropriately. 

The Solution: Go back to the basics of the framework by pursuing the original goal the Sprint Planning: Align the Developers and the Product Owner on what to build next, delivering the highest possible value to customers. First, the Product Owner points to the team’s Product Goal and introduces the business objective of the upcoming Sprint. The Scrum Team then collaboratively creates a Sprint Goal, considering who is available and the target the team shall accomplish. Next, the Developers forecast the work required to achieve the Sprint Goal by picking the right items from the Product Backlog and transferring them to the Sprint Backlog. Also, the Developers need to create a plan on how to accomplish their forecast. While this sounds straightforward, it may take time to get there, starting with creating a Product Goal and subsequently the corresponding Product Backlog as pre-requisites for Sprint Goals. No one said getting Scrum up and running for your team would be simple.

Conclusion

We do not get paid to practice Scrum but solve our customers’ problems within the given constraints while contributing to the organization’s sustainability. However, if you conclude that Scrum can support your team on that path, embrace Scrum’s first principles and checks & balances. For a Scrum team to be successful, it needs a Sprint Goal. Moreover, creating the Sprint Goal is a collaborative exercise of the complete Scrum team. If you cannot identify unifying goals, maybe Scrum is not for you.

Have you encountered Scrum teams that try working without Sprint Goals? Please share your learnings with us in the comments.