Reaching for a well-crafted Sprint Goal

A recent sprint planning session with my team got me thinking about the importance of a Sprint Goal and how it is often glossed over. When well-crafted a Sprint Goal is very valuable to the team otherwise it is just a checking off the box for "do we have a Sprint Goal", which of course isn't very useful.

Let's start by taking a look at what the Scrum Guide says about the Sprint Goal. the phrase Sprint Goal shows up 19 times in the current Scrum Guide. Under The heading of Sprint Planning - Why is this Sprint Valuable?, the Scrum Guide has this to say:

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

The PO makes sure the team understands what value they should focus on delivering in the current Sprint. The PO brings to the team the objective for the current Sprint. The team then defines the Sprint Goal in terms that are meaningful to them. So, let's dig into why this is important.

When discussing the Sprint Backlog, the Scrum Guide has this to say about the Commitment of the Sprint Goal:

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, as many things in Scrum, is about focus. The Sprint Goal focuses the Daily Scrum. Is the team getting closer to achieving the Sprint Goal? Are they focusing on the right work for that? if the answer to these questions is no, the team needs to refocus their work. This is one reason why the team collaborates to define the Sprint Goal; it needs to be worded in a way that expresses the value to them. Hopefully worded in a way that energizes the team.

As an example, a few sprints back, as a PO, I brought to the team a problem, we had a pile of work that if we didn't do soon would cause problems for our customers, for example internal passwords needed to be cycled before they expired. The team decided on the goal "defuse timebombs". To them this captured the essence of the work, allowed them to know if they were focusing on the right work that sprint, and energized them in their discussions about the work being done. 

On a previous team, we always worded our sprint goals as a haiku, with the final line being the name of a household appliance. We found it challenging and meaningful to express our goals in that form, and we had fun doing it, which also helped the team gel.

An important thing to note about a Sprint Goal is that it must be about the value of the work being completed not about the work itself. 

So, the following are not valid Sprint Goals

  • Finish all the planned stories
  • Do our job
  • Start the next epic
All of these speak to the work being done, not the value being delivered, which is what makes them poor Sprint Goals.

An additional reason why basing the Sprint Goal on the work is incorrect is that the Sprint Goal should be achievable without completing every story in the Sprint Backlog. As it says in the Scrum Guide "... it (the Sprint Goal) provides flexibility in terms of the exact work needed to achieve it". This is true when the goal is about the value of the work being completed, as opposed to being about the actual work. 

To recap, a Sprint Goal should be:
  • About the value being delivered (not the work being done)
  • Meaningful to the team
  • Achievable within the current Sprint, even if all the forecasted stories are not completed in the Sprint
Coming up with a good Sprint Goal is challenging at times, however, doing so is always worth the effort.

-Stay Agile

Comments

  1. GroupAtlanticJanuary 3, 2022 at 11:36 AM

    Les,

    Well said. Yes, it is often glossed over.

    Let's catch up soon.

    ReplyDelete

Post a Comment

Popular posts from this blog

The Five Dysfunctions and Tuckman's Stages

No, this is not a post about a new band, it is about understand Scrum team growth . In my  previous post I discussed The Five Dysfunctions of a Team by Patrick Lencioni and how the dysfunctions in that book apply not only to management teams as described in the book but to Scrum teams as well. In 1965 Bruce Tuckman proposed his model of team development. While you may not be familiar with Tuckman’s name, you have probably heard of the stages of his model, forming, storming, norming and performing. Forming - The team is coming together for the first time. Team members behave independently, they are on their best behavior and very focused on themselves. To move out of this stage, team members must be willing to risk the possibility of conflict Storming - The team members are learning each others strengths and weaknesses and learning to trust each other. Some of the teams disagreements are passionate, but also can tend to lean toward personal attacks as opposed to healthy confl
Read more

How many dysfunctions does your Scrum team exhibit?

Image
If you say your team does not exhibit any dysfunctions I have to ask you to revisit your thoughts again as that is so very highly unlikely. Most if not all teams exhibit some dysfunction some of the time, if not all of the time.  Merriam Webster defines dysfunction as  impaired or abnormal functioning or abnormal or unhealthy interpersonal behavior or interaction within a group I think both of those definitions work well with regards to a Scrum team. In Patrick Lencioni's book The Five Dysfunctions of a Team he tells a tale about the five dysfunctions that a team typically struggles with followed by a discussion of how to address them. As a scrum master it is well worth the time to read it. As far as I know the author was focusing on management teams when he wrote it, but without very much tweaking, all the same dysfunctions and corrective actions apply to a Scrum team as well.  The five dysfunctions are laid out in a pyramid. The reason for the pyramid is that
Read more

Feedback - Skills Relevant in the Torah and Today

There is a story in the Old Testament known as the Waters of Strife . It occurs when the Jews were wandering in the desert. They complain to Moses that there was no water and that they were going to die. Moses prays to G-d, the response is to talk to a rock and tell it to give water. Instead of talking to the rock, Moses hits the rock and water comes out. Aaron was punished after this incident. Reading the text in the original Hebrew, Aaron wasn't given any instructions other than to accompany Moses, which he did. What did Aaron do wrong? Why was he punished? At this point if you are still with me, you are probably wondering what this has to do with agility or Scrum. It was Rabbi Yehuda Meyers that gave me the answer to both of those questions, both what Aaron did wrong and what does this have to do with Scrum. Aaron's mistake was a simple and a common one, unfortunately one made on many Scrum teams.  First, a bit of background is needed. This event occurs right after Mo
Read more