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.
The users and customers are often very distant from the developers. Illustration by Thea Schukken
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 riskIn 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):
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.