Actual stakeholders? Or just your audience?
What makes a real stakeholder? Why that question and how to find them with three simple questions
This post is an excerpt from the book that we’re writing, the ‘Zombie Scrum Survival Guide’. It’s our way of delivering small increments and involving our stakeholders. So we’d love to hear your feedback, encouragements and wild ideas. You can also listen to us reading this post on our podcast.
When is someone a stakeholder, really?
It’s such a simple question that you can’t help but wonder why we’re even asking it. The Scrum Framework relies heavily on involving stakeholders. And for good reason. You need them to validate your assumptions and to determine what is valuable (and what isn’t).
“There is a big difference between a stakeholder and someone with an opinion about the product”
Its a simple question. Still, many Scrum Teams and organizations struggle with it. We’ve visited Sprint Reviews where all the ‘stakeholders’ present were internal to the organization; people from marketing and sales, an internal product manager and an opinionated colleague. None of them were either using or paying for the product and its development. We’ve found that not including the right stakeholders is one of the primary causes of Zombie Scrum.
This post is all about what makes a real stakeholder. And more importantly, how to find them.
Stakeholders, Users or Customers?
When we talk about Stakeholders, are we talking about Users? Customers? Internal or external customers? Product Managers? While some organizations work exclusively for external customers, many organizations also have people inside the organization that should be included in deciding what is valuable. And in other organizations, the term ‘customer’ is not something that people are used to, like in NGOs and governmental agencies.
“We see many examples where the vagueness of ‘stakeholders’ is leveraged into making teams believe that only talking to internal stakeholders is what Scrum is all about.”
For this reason, the Scrum Guide purposefully talks about ‘stakeholders’ as a placeholder for anyone who has a stake in the product. Like in a betting game — where the word ‘stake’ comes from — they personally have something to gain when the team delivers and something to lose when it doesn’t.
But particularly in Zombie Scrum, we see many examples where the vagueness of ‘stakeholders’ is leveraged into making teams believe that only talking to internal stakeholders, domain experts or intermediaries is exactly what Scrum is all about. For them, it’s not necessary to talk to the people using the product or paying for it. And that is a huge issue.
Stakeholders help reduce risk
In product development, we want to balance the user or customer perspective with a business perspective. Only focusing on one of them is going to lead to trouble. Yet in virtually all the Zombie Scrum Teams we’ve worked with, the side of the customers and the users were woefully underrepresented. This leads directly to many of the symptoms of Zombie Scrum. And it keeps risk very high.
“Risk” is the keyword here. When you are developing a product with your team, you are investing time and money into building something that you hope will return on that investment. And stakeholders — in particular users and customers — are your natural allies. By going back to them very frequently, as Scrum encourages, you can verify if you’re still on track. Are you still spending their money right? Are you still working towards solving the problem they need your product for?
So, including actual stakeholders is the best way to reduce the risk of building the wrong product and/or solving the wrong problems. But how do you find them?
“In product development, we want to balance the user or customer perspective with a business perspective.”
Three questions to find them
So while it is easy to include many people in product development and simply call them ‘stakeholders’, it is far more difficult to find the people that have an actual stake in your product. We find the following questions helpful to discover if they have a meaningful stake (and either one or more should clearly apply):
- Are they going to use or are they using the product on a regular basis?
- Are they investing significantly in the development of the product?
- Are they personally invested in solving a challenge that your product addresses?
You’ll notice that these questions are about value. A stakeholder is someone who helps you decide what is valuable to work on next because it’s important to them to get a return on their investment of time and/or money. Everyone else is your ‘audience’. This likely includes domain experts, intermediaries and other people that are interested in your product but have no personal stake in it. You can happily invite them for the ride, but you want to focus your energy and time on your stakeholders. Naturally, this perspective emphasizes the involvement of the people using your product (users) and the people paying for it (customers).
In many cases, recovering from Zombie Scrum starts by finding the right stakeholders and continuously refining who is part of that group. In this post, we clarified what it is meant by ‘stakeholders’, and offered three questions to find them. So go out and include your customers and users into the development of your product. It will be much better because of it.
Diagnose Your Scrum Team
Are you curious to learn if your organization and team are infected by Zombie Scrum? Why don’t you give the Zombie Scrum Symptoms Checker a try? It’s completely free and anonymous and offers your team a profile that helps you identify the areas for improvement.
Sign up for the book
We — Johannes Schartau, Christiaan Verwijs, and Barry Overeem — are currently up to our necks in the process of writing a Survival Guide for Zombie Scrum. It’s a hands-on guide filled with results from our on-going research and dozens upon dozens of bold-yet-practical interventions to start your road towards recovery. The book will be published by Scrum.org and Addison-Wesley in Q4 of 2020. Sign up here to stay informed and provide feedback on our writing.