In 2014, I became a Product Owner for the first time. During Sprint Planning, I understood my task as follows:
- Dictate the goal for the Sprint to the developers.
- Fill the Sprint in Jira with the appropriate User Stories.
- Present these stories to the developers during the meeting.
Wring a promise out of the dDevelopers regarding how much of it they could complete.
I didn't need more than half an hour for the presentation. The discussion that followed often lasted the rest of the day. Trustingly, I turned to my mentor—our Scrum Master at the time—and asked for support.
I saw myself as the captain of the ship. I was convinced that, as the Product Owner, I was the captain of the team. I set the direction. I determined the speed. And at all times, I had a firm grip on the helm.
Initially, he encouraged my conviction. He reminded me that in our complicated service-provider relationship with development, I probably had no choice but to specify the work in detail. But then he warned me that this approach would likely lead to every developer just "working to rule" (doing the bare minimum). And that we would never become a team that way. It took forever for me to understand the lesson behind his advice.
After more then 10 years of working in Scrum Teams and with Sprint Goals, I can state the following:
Lesson #1: Sprint Goals are not determined by the Product Owner
I am not the only one who mistook the Product Owner for a captain and believed they should define the Sprint Goal. Where does this misconception come from?
The Scrum Guide isn't entirely innocent. Let’s look at the 2013 version. In the section on Sprint Planning, it says:
"The Development Team forecasts the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal."
To be honest, I read this version as saying the Product Owner defines the Sprint Goal. In the current version, I find it described more clearly. The 2020 version provides better guidance:
"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."
Since quite a few Scrum Masters and Product Owners are unfamiliar with the latest version of the Guide, this misconception likely persists.
How do you manage to set the direction of the Sprint while strengthening the "we" feeling? For me, involving the developers in defining the Sprint Goal from the start has proven effective. I follow a four-step process:
- Everyone on the team takes time to think about a worthwhile goal for this Sprint.
- Team members form pairs and share their ideas for a goal, looking for commonalities.
- The pairs then discuss their goals in groups of four and try to combine them.
Each quartet shares its goals and the most important insights from the discussion with the whole team.
If this discussion isn't enough to find a common goal for the Sprint, a quick "Dot Voting" can be used to vote on the proposals.
Involving everyone in the team in defining the Sprint Goal will pay off: We shouldn't forget that goals help turn cooperation into real teamwork. For Sprint Goals, this is even scientifically proven. In 2007, Whitworth and Biddle found that in agile teams, commitment to team goals increases cohesion, team effectiveness, knowledge sharing, and feedback processes.
Lesson #2: Sprint Goals should describe outcomes for users
For several years, the "Outcome over Output" debate has been in full swing in the agile community.
I watch this with mixed feelings. I like to explain the difference between "Output" and "Outcome" using the Logic Model:
The Logic Model shows a development process. Inputs are used to produce new Output through activities. But Output isn't enough for a product's success. Users must actually want to use it. It must solve a problem for them. That is what is meant by Outcomes. Only results create value for the users. And we must then capture this value created for the customer back for the company—for example, by having users pay for it. That then results in an Impact for the company.
Proponents of "Outcome over Output" argue that Scrum teams must focus on "Outcomes" because only results for the customer truly represent value. I agree with that initially.
There was a time when, as a Scrum Master, I also fell into "Outcome" fanaticism. I constantly pushed the team to think more — or solely—about the outcome. Therefore, the Sprint Goal absolutely had to center on the "Outcome" (i.e., why we are undertaking this Sprint). What I overlooked: No "Outcome" without "Output."
As Scrum Masters, we must meet teams where they are and then help them step by step. And the bitter truth is: if a team is unable to deliver, then the biggest problem isn't which outcome should be the focus. Or to put it another way: The Sprint Goal "75% of users use Feature Y" is pointless if the team cannot deliver Feature Y at the end of the Sprint. In that case, the Sprint Goal should rather be:
"Feature Y is usable in a test environment and can be validated by stakeholders."
Lesson #3: Sprint Goals don't have to be SMART
Goals must fulfill the SMART criteria—the agile community agrees on that, too.
But have you ever tried to make a Sprint Goal truly SMART? In 2019, I worked in a Sprint where our team wanted to add another payment function to the webshop.
Our goal was something like: "We enable users to pay by credit card." Now let's make the goal SMARTer together:
- Specific: The goal is still quite vague. What exactly does "enable" mean? Therefore: "We integrate Visa card payment via the payment provider XYZ and ensure that customers can complete orders with it."
- Measurable: How do we determine the goal is achieved? "A user can successfully complete an order with a credit card, and the payment is recorded as successful in the system."
- Realistic: Is the goal doable in the Sprint? Probably not. Therefore: "We implement the credit card integration in test mode and perform successful test transactions."
The SMARTer Sprint Goal:
„By the end of the Sprint, we will integrate Visa card payment via provider XYZ so that users can successfully perform a payment in the test system."
And therein lies my criticism of SMART goals: Scrum is a team sport. It requires fun, motivation, and passion. Therefore, the most important question for Sprint Goals isn't whether they are SMART, but: Does our Sprint Goal have a funny or at least memorable title? Who is excited to work on it?
That’s why I can no longer remember the credit card Sprint. But I certainly remember the Sprint during the 2018 Christmas holidays at the Federal Employment Agency. Our goal was: "Keep the lights on."
The primary task of our team was to ensure operations and develop the infrastructure. Over the Christmas days, two developers wanted to finish some cleanup work. The team agreed, but only under one condition: they weren't allowed to break anything. Nobody wanted to come back early from vacation just because the systems were no longer online.
Do look for ways to accelerate your career as a Scrum Master?
Then the PSM III Bootcamp might be the next step for you.
In this cohort-based online training, you will take on the Scrum Challenge by answering 30 PSM III practice questions in 30 days to develop the skills needed to think like a Professional Scrum Master and pass the certification exam.
Join us to elevate your expertise to the highest level and drive real impact in your organization.