Identifying Sprint Goal

Identifying Sprint Goal

I have often seen Scrum Teams struggling to come up with a sprint goal during the sprint planning meeting, or they underestimate the importance of having a sprint goal at all. This happens more with teams that are new to Scrum, but it is also the case with experienced Scrum Teams. Multiple factors are behind this anomaly, which is also an antipattern for Scrum Teams.

Importance of defining a Sprint Goal:

The sprint goal provides the development team with guidance on why it is building the product increment. It acts as a pole star for the team to channel their efforts and energies, and brings to the forefront one of the most important Scrum values — focus.
The Scrum Guide says: “The selected Product Backlog items (for a sprint) deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.” From this statement, we can surmise that the sprint goal is at the heart of a sprint. It gives the sprint its purpose. Consider each sprint as a small-scale project, and together all these projects make up the product or service, which is the essence of incremental development. If, during the sprint planning meeting, a team could not identify the sprint goal, then most likely that team has not yet accurately understood the incremental development.

How to identify the Sprint Goal:

During the sprint planning meeting, the product owner (PO) defines the sprint objective, and the development team pulls those high-priority product backlog items (PBIs) into the sprint backlog, which are needed to meet the sprint objective. The product increment (PI) achieved through the completion of the core set of PBIs becomes the sprint goal for the development team. There may also be other high-priority PBIs that are incoherent with the overall sprint objective but are needed in the next PI. It is OK to include them in the sprint backlog, but these issues remain peripheral to the sprint goal. The following diagram illustrates this concept.

Scenarios: Inability to define the sprint goal

The following are common scenarios in which teams are unable to define the sprint goal properly.

  • The team is expected to work solely on defect fixing or automated test coverage expansion. The team has compromised on the quality of deliverables earlier, and the Definition of Done for earlier work was either not inclusive of test automation or it was not adhered to properly. One exception here could be that the teams have migrated midway from Waterfall to Scrum.
  • PBIs in the sprint backlog are mostly maintenance issues. A team is expected to work purely on maintenance issues, and delivering new features is not within the project scope. In this case, we should ask whether Scrum is suitable for such projects. Why not explore other frameworks, such as Kanban, which might be more effective? Ideally, Scrum should be used for accomplishing complex projects.
  • The PO is expecting the team to simultaneously work on distinct features to satisfy different stakeholders’ needs. This issue may be attributable to a lack of clarity and an inability to prioritize on the part of the PO. Another reason may be that other stakeholders are exerting pressure on the PO to deliver certain features. Whatever the reason, the PO makes the final decision on the prioritization of PBIs. The Scrum Guide states clearly that it is important for the entire organization to respect the PO’s decisions. The team can work on multiple features in a sprint, provided that these PBIs collectively deliver one coherent function, resulting in a “Done,” usable, and potentially releasable PI.
  • The team is expected to work on technical issues that do not necessarily contribute toward new features development. In some cases, the team is expected to work purely on technical issues, such as architectural changes, infrastructure upgrades, database changes, etc. It is important that the PO associate business value with these tasks and present them to the team in a holistic way. For example, migration to a document-based database may result in faster data retrieval and hence deliver increased business value. Identifying the business value associated with these tasks and not seeing them purely as technical issues will help the PO and team to come up with a better sprint goal in such scenarios.

There may be several reasons associated with the lack of a sprint goal, but those listed are common and symptomatic of a lack of Scrum understanding and poor upstream planning.

To conclude, teams that are able to define a sprint goal are more likely to achieve it and be successful with Scrum. Teams that are not yet able to identify the sprint goal should understand its importance, identify the factors that are stopping them from getting it right, and take corrective actions. The role of the Scrum Master and PO is crucial in this effort.

I am interested to know your experiences with drafting a sprint goal, challenges you have faced, and how you resolved them. I welcome your thoughts and observations.

This article was initially published in Scrum Alliance community blog –

Leave a Reply