How do you create a Sprint Goal?

If you have ever worked with Scrum, it is highly likely that you have run into problems more than once trying to define a Sprint Goal.

You may have wondered if the highest element in the Product Backlog is theoretically the most valuable. Should it be the basis for defining the Sprint Goal? Or what do we do when we have several items at the top but they are uncorrelated? Do we craft a Sprint Goal with ‘A’, ‘B’ and ‘C’? Can there be more than one Goal per Sprint?

In the previous post The power of the Goal Sprint, we saw the importance of working with Sprint Goals in Scrum. In this post we will see when they should be created and the main techniques we can use to define them, and we will explain some types of Sprint Goals.

When is a Sprint Goal created?

My advice is for the Product Owner to talk to the stakeholders during the Sprint under way and pre-agree a flexible Sprint Goal, if necessary taking to this meeting inputs from the Development Team. If they have enough time later on, the Product Owner, together with the team, may refine the items in the Product Backlog that would allow that goal to be achieved.

The deadlines depend on the Product’s uncertainty level. In a fast changing environment, if the pre-definition and the refining take place too soon, there is a risk of ruining the work that was already done, so they should be left for the last week – or even the last days – of the Sprint.

On the other hand, in a low-uncertainty environment, they could be defined and refined without the deadlines being so tight. However, care should always be exercised with dates, particularly in the case of roadmaps that extend over several months, since the stakeholders’ expectations could clash with reality.

Nevertheless, it will not be until the Sprint Planning meeting that the Product Owner and the Development Team will ‘formalize’ the Sprint Goal and its scope. This is the moment when the Sprint Goal is actually ‘born’ – after a conversation based on trust and transparency.

As a Scrum Master I have been in situations where the Sprint Goal had to be changedduringthe Sprint Planning meeting after receiving a phone call by a key stakeholder.

These extreme situations are to be avoided, of course, but, should they take place, the team must be prepared to analyze the feasibility of the goal and, where appropriate, devise a plan that allows it to be reached, negotiating its scope and aligning the expectations of the stakeholders and the sponsor.

Subsequently, it will fall to the Product Owner and the Scrum Master to convey to the stakeholders the impact sudden, last-minute changes have on the Scrum Team.

Techniques for defining Sprint Goals

Top-Down

According to this technique, the Product Owner suggests the desired future state of the Product, and the Development Team reviews the items in the Product Backlog that will allow it to be reached. Personally, this is my favourite technique as it allows the stakeholders’ expectations to be aligned beforehand with the development work the team will do.

With this model, it is important for the Product Owner to start telling the team what the next Sprint Goal will be, so that it may have enough time to refine the items that will allow it to achieve the objective, and even to start delineating its scope.

Having said that, care must be taken not to overuse this technique.The Product Owner must leave room for the Development Team to also propose Sprint Goals. For example, the Development Team may identify in the Product Backlog a group of high value items with a low development cost, so it could be interesting to tackle them in the next Sprint. Another example would be suggesting a Sprint Goal that is related with mitigating or eliminating altogether some risk for the Product.

In other words, when the Top-Down technique is used, it has to be understood that it is a two-way technique. Not only can stakeholders influence the Product Owner; the team itself is also fully capable of proposing goals.

Bottom-Up

With this technique it is the Development Team which decides, after going over the items in the Product Backlog, and in conjunction with the Product Owner, how to group and rearrange them to build a Sprint Goal.

In this case, the Product Owner does not arrive at the Sprint Planning meeting with a desired Sprint Goal in mind but with a prioritized Product Backlog; the Development Team will analyze it in order to logically group the items so that their value may be maximized while coming up with a cohesive way of working.

Apart from being perfectly valid, this technique comes in very handy when the date of the Sprint Planning meeting arrives and the goal is not clear yet. However, this is precisely why the expectations of stakeholders should be handled carefully; if problems arise during the Sprint and the scope of the work that has already been done does not meet their expectations, conflicts might arise.

Forced-fit approach (what we must not do)

I must admit that I made many mistakes when I first started using Sprint Goals as a tool. One of them was the result of following this line of reasoning: If the Product Owner has prioritized items A, B and C which sit at the top of the Product Backlog because they are by far the ones that will provide more value, then they must be included in the Sprint Goal even if they are uncorrelated.

This reasoning gives rise to highly forced Sprint Goals in which not even the priority is clear, since there are several things that are very important. A Sprint Goal must be inspiring, motivating, it must instil a sense of purpose in the team. However, an incoherent amalgamation of things can hardly be that.

Also keep in mind that one of the useful aspects of Sprint Goals is that they prevent team members from working on separate initiatives. If the Sprint Goal and the items that allow it to be achieved do not form a coherent whole, it is unlikely the tool will be used as it is supposed to.

Types of Sprint Goal

Plain, direct definition

It consists in formulating a goal and expressing it through N items in the Sprint Backlog.

For example: “Customize the Rates we offer Users,” which is expressed via items X, Y and Z. In this case, the Sprint Goal is associated with a new functionality and its scope will be defined by those items in the Sprint Backlog.

If necessary, the Product Owner and the Development Team can agree a date of production start-up and include it as part of the objective: “Customize the Rates we offer Users from the 1st of July.”

Thus, if items X, Y and Z meet the Definition of Done and the Increase is put into Production – following confirmation by the Product Owner, the team will have reached the goal on that date.

Templates

Taking the previous model as a reference, it is possible to go one step further and use templates to create awesome Sprint Goals and thereby tap their potential to the fullest.

One of the most popular templates was created by Roman Pichler, an expert in Product Management. You can find it in the following post on his blog: “A Template for Formulating Great Sprint Goals”

Apart from defining the goal itself, Roman distinguishes two additional characteristics:

• The Method, which is the answer to the question about how the goal will be reached. It might be by means of a deployable increase, a prototype in a digital format, a usability test, a spike solution, and so on.
• The Metric, which is the answer to the question about how to determine that the goal has been reached. Continuing with the example above, a metric could be: “Three randomly selected users see the prices of personalized products whose values match the values resulting from manually applying our price calculation formula; in addition, they can make purchases at those prices.”

Metaphors

Finally, metaphors can be used as Sprint Goals to light a fire under and act as inspiration for the team, while using, why not, a bit of humour to that effect.

The only limit here is our imagination. For example, if the team is going to redesign the graphic appearance of a website, the Sprint Goal’s name could be inspired in the title of the movie “The Hot Chick.”

Another example: If the team is going to improve the dissemination of contents in social media, the Sprint Goal could be Movistar’s famous advertising slogan: “Shared, life is more.”

If you are looking for inspiration, metaphors can be based on:

• Movie titles.
• Advertising slogans.
• Song titles.
• Colours.
• Sports teams.
• Car models.
• Animals.
• Etc.

Conclusions

The crafting of Sprint Goals in one part science, one part art. You can use the top-down and bottom-down techniques to define Sprint Goals, but avoid building goals that are an amalgamation of uncorrelated things.

The Sprint Goal is born during the Sprint Planning meeting by mutual agreement between the Product Owner and the Development Team. Sometimes it is advisable to have an idea for the Sprint Goal before the planning event, especially to keep the expectations of stakeholders aligned.

You can use templates to release all the power of Sprint Goals, particularly to clarify how the goal will be met/achieved and the metrics that will be used to evaluate this.

If you want to have some fun, use metaphors to come up with a catchy Sprint Goal name that will represent the objective the team is going to strive for during the Sprint.