On Stakeholders, And How To Discover Them
Why Agile teams can’t exist without stakeholders, and 10 powerful questions to find them.
“Help! We don’t know who our stakeholders are!”. It's a surprisingly common support request we receive for the Scrum Team Survey. Many Agile and Scrum teams struggle to identify and then engage properly with their stakeholders. Some teams even consider it a luxury, but not a necessity.
In this post, I will offer helpful strategies to find out who your stakeholders are. But first, I will clarify what we mean by “stakeholders” and why it is important to know and involve them.
What is a “stakeholder”?
Agile and Scrum teams exist to create a valuable product of some kind, alone or together with other teams. While this seems obvious, this isn’t always so clear in practice. Not all teams can easily trace the line from the work they do in their team to an eventual product that is delivered. What if your team delivers the infrastructure that other teams need to build the product on? What if your team is responsible for a microservice in the backend of your product? It's not always easy to know how the work of your team is valuable in the bigger picture. This is particularly a challenge in cases where the work for a product is scaled across many teams (and probably one reason to avoid scaling as much as possible).
But the keyword is value. Agile and Scrum teams exist to create something of value. The people who are best able to assess the value of the work that a team does are effectively its stakeholders. They have a clear stake in your work. If the work that your team does is of high quality, delivered on time, and suitable for their needs, they will be satisfied. But if your work is of low quality, too late, or doesn’t match their needs, they will bear the consequences of that and it will leave them unsatisfied.
Customers
One example of a stakeholder is a customer. They are the people who directly or indirectly pay for the work that you do as a team. If you deliver what they asked, they will be able to make a return on their investment. But if you mess up, their investment will suffer (e.g. they may lose money). So if your team is building a webshop platform, the shopkeepers are your customers. But your team may also be developing an internal app for which a budget is allocated in your organization, which makes the person responsible for that allocation a customer.
Users, end-users, and key users
Another example is a user or end-user. While they do not pay for your work themselves, they will be relying on your work to do their work effectively. So if your team is building a webshop platform, the shopkeepers are also users in addition to being customers. If your team is building a plugin to automate accounting in your organization, the people in the accounting department will be your users. I believe it is a warning sign if teams don’t have any users. In those cases, it raises the question of why such teams exist at all if their work doesn’t benefit anyone.
Other kinds of stakeholders
While customers and users are the broadest categories of stakeholders, other groups qualify. A product manager who is responsible for the product you are developing is one example. Their position gives them a good perspective on the value of your work. The same goes for people in a top management position (CEO, CFO, CTO) unless they are very distant from you hierarchically. Similarly, your company may have shareholders who indirectly depend on your ability as a team to deliver a high-quality and competitive product. Another kind of stakeholder could be a regulatory commission or organization that has to ensure that your product adheres to regulations.
What about Product Owners?
Is the Product Owner of a Scrum team also a stakeholder? The core responsibility of Product Owners is to know what is valuable and to ensure that your team spends its time on what is valuable. So they are a stakeholder in a sense. But I wouldn’t treat them as such, particularly when there are no other stakeholders. Product Owners are also part of the team and thus biased (e.g. by cognitive dissonance and by their proximity to the team). If you would treat your Product Owner as the only stakeholder, it would be like a restaurant where the only determination of whether or the meals are good, is to ask the chef to evaluate the meals. A more effective way to think about this is to see the Product Owner as the person in the team who primarily has to know who the other stakeholders are, how to involve them, and to know what they need.
Knowing Your Stakeholders Isn’t Optional
The thread that connects all the groups of stakeholders we identify in this post is that they are in a position to evaluate the value of the work that you are doing as a team, either completely or in part.
This is important in complex work because there are a million things you could spend time on as a team. Only a few of those will be truly valuable whereas others will be a waste of money and time. Your stakeholders are your compass to cut through the forest of possibilities and “maximize the work not done”. They will tell you what features are helpful to them and which are not. They will tell you what changes can help them make more money. They will tell you what parts of the interface are slowing them down. This is exactly the kind of feedback you want early and often as you develop a product. With every change to the product, you want to be able to ask your stakeholders to review it with you to learn if you’ve built the right thing the right way. This is relevant both to stakeholders of tangible products (like an app) and to the stakeholders of infrastructure teams or teams that develop APIs or back-end microservices. Even those teams will have stakeholders who rely on them, like other teams.
We consider it to be a critical halting impediment when teams don’t know their stakeholders, or claim they don’t have any. In those cases, Scrum Masters, Agile Coaches, and other team coaches should do everything in their power to bring stakeholders close to the teams. Otherwise, there is really no value in the application of Agile nor in the presence of such roles. Without stakeholders, you can just as well revert to plain-old waterfall project management along with all the challenges that brings.
A scientific perspective on why stakeholders are important
This is not just our opinion. It’s grounded in scientific research. Verwijs & Russo (2022) found in a study of over 2,000 Agile/Scrum teams that they are more effective when they collaborate and interact closely with actual stakeholders, like users and customers. They experience higher morale and more satisfied stakeholders. This is not at all surprising. When teams are familiar with the needs of their stakeholders, their work becomes much more purposeful. So there is a strong motivational component. It also makes it easier for teams to fulfill stakeholder needs, and thus satisfy them. High stakeholder concern is marked by a strong focus on value, proactive feedback gathering, shared goals that clarify value, and a shared sense of product ownership in teams. However, it is important to emphasize that our research also shows that these benefits are mostly lost when teams can’t be responsive to changing needs. So a high concern for stakeholders has to go hand-in-hand with high responsiveness.
One way to think of stakeholder concern is to see it as the set of mental models that team members share about who their stakeholders are and what they need. Cannon-Bowers & Salas (2001) show that clear and shared mental models contribute to teamwork and coordination, and also motivation and cohesion. Specifically for Scrum teams, Moe, Dingsoyr & Dyba (2010) report that a lack of shared mental models about desirable team outcomes impedes cross-functionality and communication. Agile methodologies like Scrum have a dedicated role — the Product Owner — to create such shared mental models. Bass et. al. (2016, 2018, 2021) identified different strategies by which Product Owners can do so. A risk here is that product ownership is constrained to a single person. Instead, a shared sense of product ownership seems more important (Kristinsdottir, Larusdottir & Cajander, 2016).
Powerful Questions To Discover Stakeholders
The discovery of stakeholders is not always clear-cut. Some teams also struggle with it because they are used to getting their requirements passed down and now have to shift to a more proactive stance. We’ve found the following open-ended questions very helpful to help teams think about, and identify, their stakeholders:
- If we would have a wildly successful number of iterations, which person or which groups of persons is most likely to thank us for our work?
- If we would deliver a crappy, low-quality increment in our next iteration, who outside the team would discover this first?
- If we would stop our work right now, who outside the team would start losing money first?
- Which person or group of persons outside the team is mostly impacted by the work we do this or the next iteration?
- Which person or group of persons is most capable of determining if a feature we deliver is useful?
- Which person or group of persons is probably aching to be more involved with our work because it affects them, but is not currently being involved by us?
- Who has a vested interest in the success or failure of our team’s initiatives?
- Who outside our teams gets nervous when we start running well behind our anticipated schedule?
- Which unexpected person or group of persons has shared the most useful feedback in the recent period?
There are many ways to leverage these questions in facilitation. You can print the questions on cards and let members of the team randomly pick and answer one card. You can also use Liberating Structures like Impromptu Networking and 1–2–4-ALL to easily and quickly identify many stakeholders.
We also recommend creating a Stakeholder Map of your stakeholders. It’s a great way to think about what types of stakeholders you have and to develop strategies for how to best engage with them. This is also a great way to think about which stakeholders can be useful allies to your team in affecting change.
How To Involve Your Stakeholders
Once you’ve identified at least some of your stakeholders, the best advice we can give you is to get them to join your Sprint Reviews. The presence of actual stakeholders transforms this from a boring meeting into a useful learning opportunity. Here are some things we like to do:
- Pass the mouse and keyboard to a stakeholder and let them click through the product with some guidance from the team. In the meantime, the rest of the team observes and identifies improvements in the user interface. We often do this for the Scrum Team Survey, as this example shows.
- Use a string of Liberating Structures to provide a nicely interactive structure to the Sprint Review.
- If stakeholders are not able to join directly, host the Sprint Review at their site instead. Or do it remotely with whatever tool you use (Zoom, MS Teams, etc).
- Use periodic surveys to collect ideas from stakeholders. Or simply schedule a moment where everyone in the teams calls another stakeholder to ask them a few basic questions, like “What feature makes you the most excited?” or “What great idea do you have that would make the product so much better for you?”.
We offer more actionable tips, do-it-yourself workshops, and 15% Solutions in the Scrum Team Survey. It's also a great way to diagnose how well your team is interacting with stakeholders and to use data to drive improvement. You can use the free version for individual teams, or use a subscription to support many more teams in your organization.
Closing
In this post, I clarified what is meant by “stakeholders”. Many teams still struggle with this in practice, as we’ve noticed in the support requests from teams that use the Scrum Team Survey. We also shared our most powerful questions to help teams identify stakeholders and offered ideas for how to creatively involve them.
Happy developing!
