For several years confusion plagued the Scrum community when using the word team. Since we had both a Scrum team and a development team, each conversation needed clarification about which team was meant. In the 2020 version of the Scrum Guide, the authors did away with the term “development team” in favor of simply “Developers,” partly in hopes of putting an end to this confusion. Finally, we have but one team—the Scrum team.
Now that this has been addressed and all confusion cast aside, I propose that there is still a second team and that it’s vital to a successful product owner. Product owners need to approach their stakeholders as team members in order to maximize communication and collaboration across that group.
Of course product owners clearly are full members of the Scrum team. Think of a Sprint Review: the entire Scrum team presents their product increment to those outside of their Scrum team. The demarcation line is clear—those inside present to those outside.
However, I have seen many product owners treat their stakeholders as a set of individuals, each with their own needs and desires. These POs run from stakeholder to stakeholder not only to gather their feedback, but also to share information between their stakeholders. They get snarled up in trying to explain to one stakeholder why a certain feature is important to some other stakeholder. They waste energy juggling the priorities of individual stakeholders. As the Bard tells us, “That way madness lies.”
Successful product owners see their stakeholders as a team instead. Just as a Scrum team does, their stakeholder team should collaborate to make decisions. This is why we suggest such activities as Luke Hohmann’s Buy A Feature to help a group of stakeholders come together to foster priority decisions. Stakeholders have to convince each other of the priority of their features: they leave the game with a common agreement on priority order.
If you have a set of individual stakeholders, here are a few ways to help them act as a team:
- Meet as a team - If you regularly have individual meetings with your stakeholders, consider regular group meetings. When you make this a routine, stakeholders will come to count on that specific time as their chance to be heard. And if some stakeholders don’t make it, they likely had higher priorities than that meeting. The stakeholders who most need to be heard will be the ones that show up.
- Hone your facilitation skills - What are you going to do with your stakeholders once you have them all together? A little facilitation skill can go a long way here. Give them multiple ways of expressing their opinions and having their voices heard. Create activities in which stakeholders discuss the product with each other. Provide the space and a structure so they can offer their ideas, consider them together, and make group decisions about them.
- Don’t treat all stakeholders equally - We have to recognize as product owners that we have different types of stakeholders. Our goal is to identify our key stakeholders and spend our efforts forming them into a team. Fran Ackermann and Colin Eden in their book Making Strategy describe this using their four-square power-interest grid. Stakeholders are either high or low interest and have either high or low power. We’re most keenly interested in the high-interest/high-power stakeholders. You’ll need strategies for each—but if you don’t have the high-interest/high-power stakeholders in the room, you may be wasting your time.
While there is only one team in Scrum, product owners will be most successful when they treat stakeholders as a second team. After all, the Agile Manifesto tells us that “the best architectures, requirements, and designs emerge from self-organizing teams.” Why wouldn’t we apply this wisdom to our stakeholders as well?
