The inability to use Sprint Goals is symptomatic of serious Product Management problems
The inability to use Sprint Goals is symptomatic of serious Product Management problems
The inability to use Sprint Goals is symptomatic of serious Product Management problems
TLDR: If you can’t use Sprint Goals this should be the least of your concerns
A while back I asked members of our Serious Scrum community what they disliked about Scrum. Don’t worry, nobody tried to burn me at the stake for asking this question. The inquiry resulted in a lively discussion full of valuable observations.
After all the discourse ended, one remark stood out to me: someone claimed he didn’t really see the point in using Sprint Goals. Their usefulness was limited to situations that were rarely applicable.
The comment stirred ambivalent feelings inside of me. On the one hand, I have little doubt about the value of Sprint Goals. On the other hand, I understand how difficult it is to apply Sprint Goals. Using Sprint Goals is demanding from a Product Management perspective. A specific set of elements need to be in place to use them with success.
I was highly skeptical of Sprint Goals before I started using them, believing they were overrated and did not matter much. I started using Sprint Goals by pure chance when I moved from one Scrum Team to another. My previous Scrum Team no longer had a Product Owner to help refine the Product Backlog or provide any direction. As a result, they struggled.
I advised my old Scrum Team to work directly with their stakeholders to set a single goal for each Sprint. Suddenly the team started delivering value every Sprint (even without a Product Owner!) and they were much happier than before. The situation still wasn’t perfect, but it was much better. This opened my eyes to the incredible power and usefulness of Sprint Goals.
Today, I believe not being able to use Sprint Goals is indicative of significant Product Management issues. For successful application of Sprint Goals, the following needs to be in place:
A strong Product Vision
Stakeholder buy-in and support
Clear prioritization
Responsibility for making sure these three elements are in order, rests on the shoulders of the Product Owner. If any of these three elements are missing, Scrum Teams will fail to adopt Sprint Goals successfully.
1. Lack of Product Vision
I define Product Vision as follows:
“A direction for where your product should be in the future that applies focus and helps make decisions about how to get there.” — What is Product Vision?
A strong product vision provides focus. It empowers people to say no and make the right decisions to move towards the desired future state of the product. A strong Product Vision acts like a lens through which to view the world. It helps to decide what matters and what does not. It makes sure each decision brings you closer to where you want to be.
Ultimately, even though the product vision seems focused on the product, ultimately it’s not about the product. It’s about how your product will make life better for the people who will use it.
Without a Product Vision, it is difficult to apply focus. This lack of focus makes it hard to implement Sprint Goals, as Sprint Goals force you to focus. If you don’t know where you want to go with your product, good luck coming up with a focused, coherent Sprint Goal. Let alone having those different goals together add up to a whole that is greater than the sum of its parts.
When you drag a group of disparate Product Backlog Items into the Sprint, the only option left on the table is crafting a faux Sprint Goal that reduces your efforts to: ‘Finish X, Y, and Z’.
2. Poor Stakeholder involvement resulting in missing their support and buy-in
Let’s imagine you’re a Product Owner with an awe-inspiring Product Vision. You’ve just nailed it and got it all figured out where the product needs to go.
In a complex stakeholder landscape, that vision is worthless unless your stakeholders endorse and support it. Otherwise, your powerful stakeholders will just drag you along for the ride to work on other things they believe are important, which likely will not move the Product Vision forward.
The Scrum Guide paints a pretty picture where Product Owners have the final say about the Product. This kind of product dictatorship works great in theory, but in the real world, where products actually get built, losing the support of influential stakeholders can undermine all of your efforts to deliver value. Stakeholder noise and resistance will make it impossible to apply the right focus to your product.
When you are at the mercy of your stakeholders, you can’t protect yourself from their whims. Moving the product forward in a single direction becomes out of the question. Your Sprint becomes a random collection of stakeholder pet projects. Once again with the same inevitable result: you won’t be able to focus and craft a clear Sprint Goal.
3. Product Owner is unable to make decisions on priority
Now imagine you are in the terrific position of having a clear Product Vision, including buy-in and unconditional trust of your stakeholders to make it happen. All stars are aligned and the whole world is smiling at you! Except, you still need to make tough decisions to bring that vision to reality. What should we do first, and why?
Making tough prioritization decisions does not come naturally to most people. It is far easier to postpone making such decisions by working on multiple things at the same time. Everything is valuable, so let’s just work on a couple of features in parallel. Making a decision is tough, as it means delaying the development of some features. It feels good to keep all of them in motion.
Doing this is the biggest mistake you can make. Keeping everything moving grants the false illusion of progress. Two things will happen:
All features will be delivered later than if you would have made a decision to focus.
You lose control over which feature gets delivered first.
To relate it back to our lovely Sprint Goal: if you work on multiple things at the same time, forget about being able to come up with a unifying and coherent Sprint Goal.
In simple words: If everything is equally important, then nothing is important.
If you can’t work with Sprint Goals, fix your Product Management issues first
The main culprit for being unable to use Sprint Goals is the Product Owner or the context (s)he needs to operate in. Without a solid Product Vision, support and trust of stakeholders, or clear prioritization, it makes no sense to start using Sprint Goals. The foundation is missing to be able to apply Sprint Goals successfully.
As much as I love Sprint Goals, fixing your Product Management foundation is way more important. Shift your attention to addressing these Product Management problems first, as it will make an even bigger difference to the delivery of value.
Even with the right Product Management foundation in place, applying Sprint Goals is still something that needs to be mastered. Don’t worry, I’ve also got you’ve covered there. I’ve written many articles on this topic in the past that may help you to figure out how to craft good Sprint Goals: