Meaningful Sprint Goals Inspire Teams to Overcome Tough Challenges
Scrum Teams can achieve the impossible with compelling Sprint Goals
Scrum Teams can achieve the impossible with compelling Sprint Goals
Product Owners are challenging people. As Product Owners, we want to change the status quo. We aim to guide teams to build delightful products. Our goals may be crystal clear, but the road is unknown. We face resistance from stakeholders and development teams. The fear of the unknown often leads to the following dreaded word being uttered: impossible. But then I ask, is it really impossible?
“It isn’t the mountain ahead that wears you out; it’s the grain of sand in your shoe.” — Robert W. Service
As a Product Owner, I’ve been in multiple scenarios, industries, teams, countries, and so on. But one attitude called my attention. Regardless of the scenario, at some point in time, I heard someone saying, “It’s impossible! We can’t do it!”
That made me wonder, how can we change this perception? I see impossible only as a state. We may believe it’s impossible because we don’t know how to do something. But we can change it if we want to. As Nelson Mandela said:
“It’s always seems impossible until it’s done.”
Scrum Teams have a powerful tool to beat the impossible. The Sprint Goal. Let me share an experience on how the Sprint Goal allowed us to change the status quo.
It’s Impossible! We Cannot Do It!
As Product Owners, we will hear people saying it’s impossible. That’s a fact which we have to deal with it. To achieve meaningful results, we should strive to change this perception. We cannot accept that impossible is a final state.
At the end of 2018, I started a new job with the mission of scaling the Marketplace solution. I was excited about it. So I thought what we could do to scale sustainably.
One recurring task annoyed me. Every Sprint, the development team onboarded four new partners. I wanted to understand why, so I asked some questions about it to the team.
Product Owner: Why do you manually onboard four partners per Sprint?
Developer: Because the business team doesn’t have a way of doing that. So we have to manage directly in the application.
Product Owner: Hum. It sounds like an operation responsibility. Have you ever considered changing this scenario?
Developer: Well, it’s a simple task for us to perform manually. It’s only some copy and paste stuff. But it’s okay. So we never considered doing something different.
Product Owner: I think if we keep this responsibility with us, we will have less space to focus on scalability. What if we could build something where the business team could onboard the partners without our help?
Developer: That’s impossible. We do it manually because we have to adjust the application, and then deploy it. For us, it’s simple. But to provide an interface for the business is not doable.
After this conversation, I understood we had an opportunity to change the onboarding process. But before jumping into action with the team, I needed to acquire some more understanding from the business side.
I talked with the marketplace director. He shared with me the challenging goal of onboarding 300 partners in one year. At that moment, it became clear we had to do something. Our current process would allow us to onboard around a hundred partners only, very far from the goal.
We could increase the number of onboardings per Sprint, but which development team would be motivated by it? I guess no team would be interested in having half of the Sprint filled we recurring tasks. However, I also knew the way the development team perceived a change within this process. I thought, “It’s time to move from impossible to possible!”
The Power of The Sprint Goal
The challenge ahead of me was frightening. On the one hand, we had a process that would not lead us to the result we wanted. On the other hand, the development team believed it would be impossible to change the current process. I needed to find a way out of this deadlock.
My mission was to give the development team the space needed to change their perception. I needed to have a compelling goal to achieve, which would foster collaboration as well as motivating the team to overcome our challenge. The answer for that was clear: the Sprint Goal. Let’s have a look at what the Scrum Guide says about it.
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 Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.
— The Scrum Guide, November 2017
During the next Sprint Planning, I had a clear goal in my mind. But I had no idea how we could achieve it. The conversation went like this.
Product Owner: Guys, for this Sprint, I have a significant challenge for us. We should allow business to onboard the partners without our help.
Developer: I think I told you, we cannot do that. It’s impossible. Currently, it requires a deploy whenever a new partner is created.
Product Owner: Why do you see that as impossible? What could we do to change it?
Developer: Well. The problem is with how we onboard the partners. We need to create some classes manually. If we want to allow the business to do it, we need to go through a massive refactoring. That’s a lot of complexity.
Product Owner: We have to integrate 300 partners in a year. Currently, we integrate four per Sprint. We will not reach our goal if we don’t change the status quo. I don’t think you want to start onboarding twelve partners per Sprint. My question is, what can we do to find a solution for it?
Developer: I get your point. It’s true, and we need to find an alternative. But we need time for that.
At this moment, I noticed the team was willing to try something different. But they needed a space to find a solution. So we crafted our Sprint Goal as “Have a concept on how to onboard the partners without help from the development team.”
The team had a challenging goal to achieve. However, it was unclear how to achieve it. In the beginning, the developers decided to explore different ideas. The Sprint Backlog didn’t matter; achieving the goal was the focus. The team engaged in the mission. Together they could find a technical way of implementing a solution. The goal motivated them.
During the Sprint Review, the development team was excited. The Sprint Goal was reached; the team had a concept for our problem. But the team went beyond that. The team built a practical approach. Yet, only technically usable, but it would allow us to take the next step. It was not impossible anymore, and we could implement a solution.
The development team was eager to implement the solution. They were audacious during the next Sprint. We crafted a compelling goal “The business team does onboarding process.” At the end of the Sprint, we had a solution deployed on the live environment. From that moment on, business handled the partner onboarding autonomously.
It took us two Sprints to move from impossible to possible. I attribute this success to the Sprint Goal. Without that, the development team wouldn’t have a chance to collaborate intensively. The challenge motivated everyone to change the status quo.
Endnote
The Sprint Goal is powerful, yet many teams fail to benefit from it. Many teams give up crafting Sprint Goals because they focus on the output instead of the outcome.
An excellent Sprint Goal will foster collaboration. It will give the team the space to be creative, to search for out of the box solutions.
We should not ignore the benefits of Sprint Goals. We should strive to define compelling goals for the team. It requires courage and discipline because defining goals mean focusing on what is essential and saying no to all the distractions.
Do you want to write for Serious Scrum or seriously discuss Scrum?