Does a team need a Sprint Goal in Scrum?

The cross-functional, self-managed Scrum Team is waiting to fall from the sky of increment.

Recall what the official Scrum guide says about the Sprint Goal:

The Sprint Goal is the only goal on the Sprint. While Developers is committed to the Sprint Goal, it provides flexibility in terms of choosing the specific work needed to achieve it. The Sprint Goal also provides coherence and focus by encouraging the Scrum Team to work collaboratively rather than on separate initiatives.

The Sprint Goal is created during Sprint Planning and then added to the Sprint Backlog. Developers keep the Sprint Goal in mind as they work on Sprint issues. If performance does not meet expectations, they work with the Product Owner to revise the content of the Sprint Backlog within Sprint without changing the Sprint Goal….

During Sprint Planning… the entire Scrum Team together defines the Sprint Goal, which explains why Sprint is valuable to stakeholders. The Sprint Goal must be formulated before the end of Sprint Planning.

There are several benefits to using the Sprint Goal:

a clear focus of the team while working on achieving the goal
criterion for making changes to the work (whether they will help achieve the goal or, on the contrary, interfere)
motivating factor in work, encouraging, among other things, mutual assistance and teamwork
transparency of team work for stakeholders (stakeholders)
criterion for determining the effectiveness of work on the review of the sprint and retro session

But setting a sprint goal can be quite challenging for a team, and many teams struggle with it. But this is a regular process, every sprint planning has to do this (on average, plus or minus once every two weeks). If the team itself does not see the benefit of this artifact and considers the formulation of the goal a waste of time, they most likely will not do it. As a result, after several initial sprints in the project (according to experience, the initial fuse lasts from 1-2 months to six months) or everyone is hammered into it with the argument: “We cannot make such a commitment, all these strict goals and deadlines are not Agile“, “It doesn’t work for our team.“, “The client does not care for these purposes, so there is nothing to waste time on them“etc. Or the goal is determined by the product owner / manager by order (in teams working on “manual control”).
Sometimes a sprint goal becomes a multi-goal when the team cannot determine what is important for the client, what benefit this increment will bring to him, and includes several points in the Sprint goal. Not to mention the Level 80 Goal: “Close all those damn tasks for this sprint!“

Lack of a clear sprint goal can cause the team to lose focus, so what? important to do in a sprinteveryone will do those tasks that seem to him now a priority (“who is in bug fixing, who is behind technical debt“). As a result, at the sprint review and retrospective, instead of discussing progress in achieving the Sprint Goal, team members pay off with meaningless phrases “everything seems to be normal, everything is as usual, there are no comments.” About the proposed improvements, which should ideally be based on the results of the retro -Sessions added to the backlog, no need to say.

I met such projects and teams in practice, the result is almost always predictable – defocusing of the team, quick loss of motivation among developers, lack of improvements in work, constant transfer of unfinished tasks to the next sprint, delivery of a new release every 2-3-4 months. And now, instead of Scrum, you have only an essentially empty cargo cult, and the management is looking for a replacement for a new manager or Scrum Master, because this “broke down“…

Meanwhile, instead of telling the team to “do your best to formulate a good Sprint Goal,” you can look at what obstacles there are in formulating a relevant Sprint Goal. The team fears negative consequences if the goal is not achieved. Too short sprints. The product owner lacks authority. Too many external dependencies. The tendency of senior management or clients to jot down “urgent high priority” tasks.

Don’t ignore setting a goal for the upcoming sprint, it can be a very useful tool if used correctly. Remember where the official Scrum guide starts:

Each element of the framework serves a specific purpose, necessary to achieve the overall value and results from the use of Scrum. Changing the core ideas or structure of Scrum, omitting elements, or not following the rules of Scrum tends to hide problems, limit the benefits of Scrum, and potentially even render it useless.

Do not try to convince or force people to formulate a goal – rather pay attention to identifying and removing obstacles on the way to it.