A deeper understanding of…

The Sprint Goal

Road to Mastery — Season 2 — Episode 2

“Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.” — The Scrum Guide.

The way I imagine an ideal briefing from the Product Owner to the Development Team is like presenting a love letter 💌.

“Dear Development Team … ,”

The Development Team (being the value creators) should truly love and value those who they are creating the value for and they should be loved and valued for it in return

The importance of a Sprint Goal, which is crafted during the Sprint Planning can be underestimated. Some teams don’t even bother. However, in Scrum, and being serious about Scrum, the Sprint revolves around the Sprint Goal.

“It provides guidance to the Development Team on why it is building the Increment.” — The Scrum Guide.

It’s a mission that provides a purpose for the whole team.

“We set sail on this new sea because there is new knowledge to be gained, and new rights to be won, and they must be won and used for the progress of all people.”

“But why, some say, the Moon? Why choose this as our goal? And they may well ask, why climb the highest mountain? Why, 35 years ago, fly the Atlantic?”

“We choose to go to the Moon! We choose to go to the Moon…We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard; because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one we intend to win, and the others, too.” — John F. Kennedy Moon Speech

A Sprint Goal serves to promote self-organization and creativity. It establishes the ‘why’ so the Development Team can work out the ‘how’. Therefore, a great goal could be like an open question that the Development Team aims to answer with the next increment.

“The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.” — The Scrum Guide.

In a complex environment, we need to look for the right questions that address complex adaptive problems. In complex, chaotic, and even shitty conditions, the Sprint Goal will enable the team to perform well.

Crafting Sprint Goals

The Product Owner doesn’t dictate the Sprint Goal, but discusses the objective that the Sprint should achieve. The Scrum Team collectively aligns on what the Sprint Goal should be.

To answer how to approach crafting a Sprint Goal, it is best to understand what distincts empirical process control from defined process control.

‘Defined process control’ builds on defining what is known, what steps / task will get you there. This works best in stable environments for simple challenges.

‘Empirical process control’ builds on exploring the unknown and figuring out the best steps along the way. This works best in changing environments and complex challenges.

Overly prescriptive goals can be real idea killers. To be true to empiricism in Scrum, Sprint Goals could be more like a call for a quest or adventure: exploring the unknown. Setting a goal in Scrum should not be about ‘defining’ expected output (that would be more fitting for ‘defined process control approach’).

Example of a ‘‘defined’’ Sprint Goal: “Implement throbberflopter on the blobberboard to stabilise quadroflow at 15% to stop the humming noise from making our space hikers feel nauseous”.

This goal is very specific and clear and makes for a great Sprint Goal if the conditions aren’t all that complex or adaptive. It already specifies the answer to the problem and explains how the team should solve it. But… it is a task, not a goal. The task is specified and so is the expected outcome. What’s more, cause and effect are already known.

But what if this wasn’t known already? In a more complex environment, this would have resulted in a different goal.

The Sprint Goal enables flexibility in the plan. This would not have been the case with the Defined Sprint Goal. As long as the Sprint Goal is not put at risk, the team can respond to change. Changes are valuable and so are newly discovered complexities. Newly discovered complexities are no longer considered a ‘danger to the plan’ but instead they are considered to be ‘valuable learnings’.

Phrasing the Sprint Goal as a single value proposition allows the team to let their imagination run free, yet still remain focussed, while putting their expertise to use.

“Sprint Goal to the Scrum value of Focus — the Sprint Goal is our guiding North Star, or like a lighthouse guiding a ship in the fog.” — Chris Belknap

Example of an “empirical” Sprint Goal where the solution isn’t known:

1. Is there a way to stop the space hikers from feeling nauseous?

Questions spark off an active inner search process. Questions spark the drive to solve something. Answering questions and solving puzzles is more motivating for a team than obeying orders. One thing to note though: questions shouldn’t be answered, but solved if they are to serve as a goal. So a simple ‘yes’ or ‘no’ won’t do. It cannot be answered with theory only. It has to be answered with a tangible result: the Product Increment. The Increment should serve as the answer.

The Development Team can work out how it can approach this and through collaboration, they can work out their own thesis:

1. How can we learn what is making the space hikers feel nauseous?
2. Is there a relation between the humming noise from the Hiker’s Quarters Deck and nausea? [assumption]
3. If so, how can we learn what causes it?
4. If so, how can we safely reduce it?
5. Would stabilising quadroflow reduce the humming noise? [hypotheses]
6. Would implementing a throbberflopter on the blobberboard stabilise quadroflow? [hypotheses]

Through this thesis, the Development Team can best create their own flight plan (part 2 of the Sprint Planning).

It could very well be that through this objective the team will learn that indeed there is a correlation.

“Lead with questions, not orders.”

-General George S. Patton Jr. famously advised leaders never to tell people how to do things: “Tell them what to do, and they will surprise you with their ingenuity.” Rather than give orders, leaders in agile organizations learn to guide with questions… ” (source)

Naturally, when the specifics are known upfront there is no need to be vague. But let’s go back to the “defined” Sprint Goal example. What if it turned out the throbberflopter wouldn’t have stabilized it. What if the humming didn’t cause nausea? Their tasks would be executed successfully but without achieving the expected outcome.

Question to ask yourself about the Sprint Goal

• What makes it worthwhile to run this Sprint?
• What sets this Sprint apart from other Sprints?
• What sets the Sprint Goal apart from a Product Backlog Item, User Story or a Feature?
• How does the Sprint Goal provide coherence for creating a Forecast?
• How does the Sprint Goal stimulate the Development Team to self-organize?
• How does the Sprint Goal motivate the Development Team?
• How does the Sprint Goal stimulate the Development Team to work together as a team?
• Why does achieving it make us proud?
• How does achieving the Sprint Goal add value?
• Is there a right mix between ambition and reality (based on past experience)?
• How does the Sprint Goal enable flexibility in the plan to achieve it?
• How does the Sprint Goal provide focus for the Scrum Team?
• How can the Development Team make progress visible toward the Sprint Goal?
• How can we celebrate the Sprint? (addition by Chris Belknap)

Tips & tricks towards creating Sprint Goals:

• Try open-ended questions that inspire the Development Team to answer the ‘how’: “How can we…”, “What could be a great way to…”, “Is there a way to…”.
• Try goals without any ‘ands’. They should be to the point. Remember, the goal is a single proposition the team can focus on. It’s also about setting a single top priority.
• Try goals that don’t prescribe solutions, methods, tools, and processes. The development team self-organizes how they go about solving a complex challenge.
• Try phrasing the goal as a puzzle to solve or a quest to embark on.

Having said this, the Sprint Goal shouldn’t be too vague either. An open-ended Sprint Goal should not result in an open-ended Increment. So what are good ways to make the Sprint Goal specific enough so the team doesn’t get lost in the woods?

• Apply the FOCUS acronym. By Maarten Dalmijn
• Specify outcomes: what changes in behavior could indicate that a team achieved its goal?
• Declare assumptions: What are assumptions that could be validated or debunked through achieving the goal?
• Specify hypotheses: What results (output), or changes in behavior (outcomes) are we expecting that prove our assumptions to be correct?

Approaches and techniques that can be applied:

• The Lean UX Canvas
• Product Vision Template
• Kickstart Catalogue
• Business Model Canvas
• Value Proposition Canvas
• Guide to Evidence Based Management

The Daily Scrum

What do the three suggested questions for the Daily Scrum all end in? Right they are questions about meeting the Sprint Goal. The Daily Scrum serves to create transparency over the progress towards the Sprint Goal and provides the Development Team an opportunity to inspect and adapt.

So imagine a team running into an impediment towards a PBI? Should we focus on this? Well, the Sprint Goal can guide the team through simple questions like:

• ‘Does it endanger the Sprint Goal?’
• ‘Does this discovery make the Sprint Goal obsolete?’
• ‘Is resolving this impediment more valuable than staying focussed on the Sprint Goal?’
• How will we make this newly discovered complexity transparent?

The rules

Scrum comes with its sets of rules for the Sprint Goal. The way the Scrum Team formulates the Sprint Goal is to be self-organized. For example, although I suggested formulating The Sprint Goal as a question, this is not something Scrum prescribes. Scrum does not have any written rules about how to phrase the Sprint Goal.

What may be, could be, must be.

The Scrum Team has to be able to commit to the Sprint Goal.

Good Sprint Goals could aid the team in creating a selection of coherent Product Backlog Items. This selection is called a Forecast by the Development Team.

The Sprint Goal enables a degree of flexibility in what the Development Teams will choose to implement.

“The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal.” — The Scrum Guide

The Sprint Goal is paramount and may not be put at risk. Although Scrum enables flexibility during a Sprint, this flexibility may not endanger the Sprint Goal.

“No changes are made that would endanger the Sprint Goal” — The Scrum Guide

The progress towards the Sprint Goal must be inspected and the team must stay focused on making progress towards it. For example, the Daily Scrum has to be all about focussing on progress toward the Sprint Goal.

“Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.” — The Scrum Guide

The Sprint Goal promotes collaboration. Each member personally “commits to achieving the goals of the Scrum Team”.

But can changes be made to the Sprint Goal?

Well, this is a tough one. The Scrum Guide does not explicitly state that it is immutable, but neither is it mentioned anywhere that it can be updated/adapted. A Sprint Goal could become obsolete and this may be a reason to cancel a Sprint.

“Let’s skip the Moon and head straight to Mars”

Whenever changes to the Goal are suggested, this may hint at an underlying issue that should be addressed. Adapting the Sprint Goal might obscure an underlying defect. Perhaps the goal was not clear to begin with. Perhaps there was a lack of transparency between the team and stakeholders. Perhaps the Sprint length is not in tune with the pace of change in the market and customer demand.

What can be said of Focus when the Sprint Goal changes, or about Commitment? Is the Sprint Length too long to timely adapt to changes in the market? Hoe does it impact transparency to stakeholders when a team suddenly adapts to a new goal?

I engaged the community and asked various Scrum Masters and Scrum Trainers and am intrigued by the variety of responses.

“A Sprint would be cancelled if the Sprint Goal becomes obsolete.” — The Scrum Guide

There doesn’t appear to be a shared understanding about what ‘obsolete’ means: would making even minor changes make the original goal obsolete? Also, as no changes can be made that endanger the Sprint Goal:

“Does changing the Sprint Goal endanger the Sprint Goal?” — Willem-Jan Ageling

It very rarely makes sense to adapt a Sprint Goal and personally I would refrain from encouraging it. That said, through a lot of if’s… IF the team made some valuable discoveries and IF it enables them to unlock hidden treasures along the way… IF it is about reacting quickly to new opportunities, IF a team can end up somewhere better than what it originally aimed for and IF it therefor embraces empiricism… adapting the Sprint Goal can be true to the nature of Scrum.

Is the Sprint Goal ‘Safe to Fail’?

Naturally, the team commits to achieving the Sprint Goal, but what if it learns it can’t be, given the Sprint’s time-box? How can the Scrum Team best adapt?

“Okay, Houston, I believe we’ve had a problem here”

Should the Sprint be cancelled? Well, does whatever is impeding the team from achieving the Sprint Goal render the Sprint Goal obsolete? Would this cause something else to be more valuable to focus on? If that’s a ‘no’, please no, don’t cancel the Sprint. The attainability of the Sprint Goal is not rigidly bound to the Sprint Cadence. In fact, please continue. The Scrum Master can help the team remove impediments. When a team is challenged, they should not ‘give up’, they should keep inspecting and adapting as best they can.

What about the Sprint Review, what if there is nothing to demo? The Sprint Review serves to optimize value and to create transparency between the Scrum Team and stakeholders. Achieving the Sprint Goal is not a prerequisite to having a Sprint Review. Share your challenges and discoveries with them and let them help guide the team on what best to do next.

Must they work overtime? The team will agree to do its best to achieve the goals of the team. Instructing them to work overtime if they are challenged, will not motivate teams to set ambitious goals, on the contrary! That said, if the Sprint Goal is truly motivating, the team members might be intrinsically motivated to pursue it beyond regular office hours. Their call. Consider however that the pace should be sustainable. Sprints aren’t meant to be death marches. If the team works overtime on a regular basis, this can give the wrong impression and set the wrong expectations with stakeholders about past performance.

Do we celebrate learnings? When a team is challenged it could be because they had not anticipated something.

“In complex environments, what will happen is unknown.” — The Scrum Guide

They learned something. If these learnings (and yes they include defects/bugs/debt you name it) are not valued, and instead the team gets blamed for them, how eager/motivated do you reckon the team will be towards making them transparent and resolving them in the future? As a Product Owner/Scrum Master/Stakeholder: What would be more helpful? What is more likely to promote trust moving forward? blaming the team? or thanking the team for sharing these challenges and asking them what they need to resolve them or prevent them from moving forward?

How to act when the Sprint Goal is challenged? This comes down to Scrum’s values.

• The Scrum Team stays committed to trying to achieve the goal.
• It’s time to show courage to do the right thing and work on tough problems.
• Make impediments visible. Discuss these so the whole Scrum Team has a shared understanding of the challenges. This does not need to wait until the next Daily Scrum.
• The Scrum Team and its stakeholders agreed to be open about all the work and the challenges with performing the work. So challenges and progress are to be made transparent to all stakeholders.
• Work with the Scrum Master on how to resolve these. Adapt the plan to what the best next first steps would be. Keep monitoring progress and making progress towards the goal visible.
• Everyone should focus on the goal and resolving impediments towards it. The scope may be clarified and re-negotiated between the Product Owner and Development Team if this helps the team to focus.

How to redeem from a failed commitment? If the team had put in its best efforts and acted in good faith living the Scrum Values, it did not fail its commitment even if the Sprint Goal was unattainable. The Scrum Team collaborates to inspect and adapt during the Sprint Review and Sprint Retrospective. Together they determine if the Sprint Goal should still be worth pursuing the next Sprint and work out what best steps to take next.

Closing argument

Teams that don’t put in the effort to craft Sprint Goals will more than likely lack commitment, focus, creativity, and flexibility during a Sprint. If crafting the Sprint Goal is rushed and if the Sprint Goal isn’t all that clear, so will the outcomes of the Sprint.

So take a breath. Take the time and pour lots of love into crafting Sprint Goals. I hope this article is helpful.

I would love to know your thoughts and techniques. I hope you can share them here for other readers.

Thank you Chris Belknap, Willem-Jan Ageling, Maarten Dalmijn and Ionut-Adrian Bejenaru for reviewing and exchanging thoughts on this deep-dive.

“Lots of love… ”

The Road to PSM III is being reformatted to The Road to Mastery! Part I: Down the Rabbit Hole is now available.

Continue: