What’s the deal with the Sprint Goal?

The Sprint Goal? Necessary? Or problematic? What should it be like? Should every team member be involved?

These are just a few questions that begin to emerge after working with the Scrum framework for some time. In my opinion, they are unavoidable and will inevitably arise sooner or later. If you’re among the lucky ones who haven’t experienced these profound, metaphysical considerations, refer to the first point, or it might just be a case where the exception proves the rule 😀

The topic remains current, and I admit that I started drafting the first outline of this article in March of this year, and it kept coming back to me, interestingly with only slight context changes.

Time for Scrum Guide: To answer precisely, let’s return to the source. What does the Scrum Guide directly say about this artifact? I base my considerations on its latest update from November 2020.

The Sprint Goal (aka Sprint Goal) is a key element that gives direction to the team’s work during a sprint. It is determined during planning (Sprint Planning) and serves as strategic guidelines for what is to be achieved in the upcoming timebox.

So:

1. It gives the team a clear direction and goal to aim for.
2. Helps maintain focus on the most important tasks – these enable achieving larger product goals.
3. Acts as a guidepost, a decision criterion in case of changes during the sprint – modifications should support the goal, or at least not hinder it.
4. Allows for team self-organization and adjustment/correction of the plan as needed. We look at the goal and adjust to it.

The Sprint Goal is related to the items/tasks chosen from the sprint backlog but is more strategic and tied to the value that the team commits to deliver. Although often determined by business aspects and thereby very specific functionalities, it’s not always the case. Often, the direction is set by prototyping, learning, or other aspects of work that long-term enhance the product’s value or simply the team’s efficiency.

What does it look like in practice? I’ll answer like a typical IT professional – it depends.

Time for a digression: In Poland, Scrum is still in its infancy, and various types of so-called scrumbuts are emerging. But as the softwarehouse type companies themselves are increasingly adapting to the framework, contracts between clients and software providers often aren’t scrum-based, including the client sometimes not being Agile and delivering requirements in various forms.

Is it a mandatory element? Or just nice to have? From the Scrum Guide, it follows that the Sprint Goal is an artifact that is highly recommended and indicated. From life, however, I can say one thing – a “tip and trick”:

If we ponder over 15 minutes during planning and can’t reach a consensus, then it’s not worth forcefully struggling with it. It’s a waste of time. Then I pay special attention to the order of tasks in the sprint backlog and their priorities. In such a situation, I treat this order as the team’s commitment, leaving at the bottom things that might always be at risk of being dropped or replaced – something might go wrong.

Nevertheless, such a situation, when it starts to repeat, should be analyzed. It may indicate several issues:

1. Complexity of work: The project may be so complex that different tasks require varied skills and can’t be gathered under a single common goal.
2. Team size: The team may be so large that they are working on different aspects of the product simultaneously, making it difficult to focus on a single goal.
3. Project phase: The team may be in a phase where different work paths (e.g., research, prototyping, feature development) are being pursued in parallel.

In such situations, the Scrum Master and Product Owner should cooperate with the team to understand the causes and try to find a way to better define the Sprint Goal. Sometimes this may mean a need to restructure tasks or even divide the team into smaller, more focused groups. The Sprint Goal should still be used as a tool to ensure clarity about priorities and direction of work, even if it requires more flexibility and creativity in management.

What did it look like for me over this year? Mainly the problem, as I mentioned in one of the articles, stemmed from the size of the team. The larger it was, the more problems I observed. Additionally, the complexity of the project gives a sign from time to time 😀

Should every person on the team be involved? In my opinion, this is not a good assumption. In an ideal world – yes. However, from experience, I know that with larger teams and complex projects, it could lead to very broad goals.

What does it look like for me? I always strive for the goal to be directly related to the business value for the client – sometimes it may not be specified directly, but when we look at the long-term context, it certainly is.