The power of the Goal Sprint.

"Is it a Fortissio Lungo? Because it smells great", asked Gonzalo, Product Owner of the Telcom Team, just before starting Sprint Review #4. I had joined the team a couple of days earlier as a Scrum Master and in the midst of the calm and with the smell of coffee, I could not have foreseen the storm that was brewing.

Less than 20 minutes had passed when Alonso de Benavides, the main stakeholder and sponsor of the project, launched the question that rumbled like thunder in the room: "So, can someone tell me what the hell was done in this Sprint?".

To which Gonzalo responded in a tremulous voice: "The team has finished the TL-34 and TL-35 tours related to the user area, and also the TL-40 to TL-44, which have improved the loading time of the product catalog pages".

Alonso's face turned blue at times. In the room everyone looked at him, while they held their breath, without understanding why he reacted like that.

Alonso, having been subjected to great pressure for months, stood up, as if to reinforce his message, and added: "I told you it was vital for the company to be able to sell the new TV-Streaming product at the end of this Sprint, since our competition is crushing us as theirs was released to the market two months ago".

Gonzalo, who vaguely recalled mentioning this to the team during the Sprint Planning, replied, almost with a broken voice: "I'm afraid that the team did not have time to finish up the Jiras for that functionality, they got stuck and decided to continue with other things to complete more items of the Backlog without bringing the speed down".

After hearing his reply, Alonso smiled slightly, one of those smiles in which the mouth makes a stiff grimace and the rest of the face remains motionless.

After a few seconds of utter silence, he said while he was leaving the room: "I'm afraid you haven’t understood anything and it's very disappointing. You have not understood the priorities of the business, what adds value and makes us support this company. You cannot distinguish the important from what is unnecessary. It is a very worrying situation that I hope you will solve in the next Sprint or I will have to take measures”.

I could not help thinking that none of this would have happened if the Scrum team had learned the power of the Sprint Goal. The good news is we got something positive out of the situation as we had an opportunity to perform Inspect-us and Adapt-us in the next Retrospective.

What is a Sprint Goal?

The Sprint Goal is the most important goal that the Scrum team has to meet during the sprint. It must be achievable by making a "coherent" set of Product Backlog items.

This set can represent either a functionality or anything else that serves for the team to work in a common cause, rather than in separate initiatives.

The Sprint Goal guides the Development Team to know why they are building "this" Increment. If during the sprint it is discovered that the work to be done is different, the Development Team and the Product Owner can renegotiate the scope of the Sprint Backlog during the sprint.

On the other hand, the Sprint Goal also helps the stakeholders, the Product Owner and the Development Team to be aligned on what is most important, the highest priority. That is, it guides the work of the team and determines, and to a large extent, the expectations of the stakeholders.

Generally, the stakeholders and/or the sponsor will be satisfied if the team reaches the Sprint Goal. Do not forget that the Sprint Backlog is a prediction of the work that the team will do, while the Sprint Goal is a commitment.

The Product Owner is responsible for managing, on the one hand, the expectations of the stakeholders and, on the other, the definition of the work to be carried out, through collaboration with the Development Team.

In addition, it is a tool that honors the values ​​of Scrum:

• Focus: the Sprint Goal serves as a beacon that guides the team to develop the top priority.
• Commitment: the team is responsible for fulfilling its mission, the Sprint Goal.
• Courage: you have to be brave to meet the objective, solve the obstacles that arise along the way, overcome the "thieves of time", redirect a partner who, without realizing it, deviates from the goal.
• Openness: the follow-up of the Sprint Goal during the Daily srum forces transparency around the degree of achievement, the impediments that may appear and that must be made visible in the re-planning of tasks that may emerge.
• Respect: the Scrum team respects the stakeholders and the sponsor, assuming the Sprint Goal as the fundamental objective, the one with which they commit themselves.

Do you want to know what are the 10 powers of the Sprint Goal?

• It serves as a guide to the Development Team and helps you focus on what is most important in the sprint.
• If things get difficult, it facilitates decision-making based on priorities.
• Provides a purpose, gives meaning and motivates the Development Team.
• It promotes the cohesion of the Product Backlog items towards a common goal.
• It is polymorphic: it can be used to deliver functionalities, test ideas, reduce risks, etc.
• It allows the Product Owner to manage the expectations of the stakeholders and align them with the work carried out by the Development Team.
• It makes the Development Team's work more flexible in two ways: its scope is negotiable and, normally, it only represents part of the work of the Sprint Backlog.
• With caution, use the Product Owner to create Roadmaps.
• It serves to reduce the risk of the Product; each sprint can be considered as a mini-project with a defined objective.
• In the Sprint Planning, it serves to focus on the common objective and the Daily Scrum, allows to guide the event.

How does the Sprint Goal relate to the delivery of value?

Although it may seem an innocent question, in reality, it is not. In Paradigma we repeat, almost like a mantra, that the Product Owner is a maximizer of the delivered value.

Therefore, if the Sprint Goal is the most important thing the team has to do during the sprint, can we infer that the Sprint Goal must represent the most valuable thing that the team can do? For me the answer is "not necessarily so".

And this happens for a fundamental reason:

According to the Scrum guide, "... the Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives".

That is, the Sprint Goal can be anything that provides coherence to the work done by the Development Team. A Sprint Goal can be related to the treatment of a risk of high probability of occurrence and high impact.

Perhaps, during the Sprint Planning, in the upper part of the Product Backlog there was a functionality that would bring great value, but the Product Owner and the Development Team can agree that dealing with risk is more important than delivering that functionality.

At this point, frankly, only your imagination is the limit. There are authors who claim that a Sprint Goal can even be the name of a music group, of a videogame ... as long as it represents a common goal for the team's work.

Personally, I prefer specific Sprint Goals, directly related to the delivery of value, but both approaches would be valid according to the framework.

When the Sprint Goal becomes obsolete

Finally, it is important to note that the Sprint Goal also serves as a criterion to cancel the sprint in progress. If the Sprint Goal stops making sense, becomes obsolete, or changes in the market, technology, etc., the Product Owner can decide to cancel the Sprint and start a new one. However, given the brevity of the sprints, it rarely happens.

Conclusions

Our friend Gonzalo, Product Owner in the story I told at the beginning, could have saved the embarrassment during the Sprint Review had he known the power of a Sprint Goal. Without a clear objective, it is very easy to lose focus and not meet the expectations of the stakeholders and the sponsor.

The Sprint Goals serve as a guide to the Development Team, promote team focus, facilitate decision-making based on priorities, allow alignment of stakeholder expectations with the work of the Scrum team and are so flexible that they can be used to deliver functionalities, deal with risks, perform tests, etc.

In the next post "How to create a Sprint Goal" I will give ideas to define and model Sprint Goals in practice.

Stay tuned!