Myth: Only The Product Owner Interacts With Stakeholders
Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘mythbusters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. The great visuals are by Thea Schukken. Check out the previous episodes here.
If you prefer, you can also listen to us reading this post.
We recently spent time with a Development Team that spent an hour debating an unclear requirement. Without the Product Owner present, they felt unable to further clarify it. But as it turned out, a 1-minute phone-call with the user that suggested the item clarified everything. Up to this point, the Development Team was convinced that talking with users was the responsibility of the Product Owner.
Perhaps you recognize this. You may also recognize a Product Owner who claims exclusive responsibility for talking with users. Or the Product Owner as the only member of a Scrum Team who identifies and clarifies work for the Product Backlog.
Today we bust the myth that the Product Owner is the only person on a Scrum Team who interacts with stakeholders, like users and customers.
Busting the Myth
The Scrum Guide states that the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. This work is made transparent on the Product Backlog, and is managed by the Product Owner. In order to determine what work is valuable and in what order, the input of stakeholders is obviously needed. However, nowhere in the Scrum Guide is it stated that the Product Owner is the sole person responsible for communicating with stakeholders.
In another example of making an interpretation of Scrum more important than it’s purpose, the idea that only Product Owners interact with stakeholders goes against what Scrum wants to make possible. Scrum is built on the experience that product development is a very complex affair. Discovering what is needed, and how to best implement it, requires the Scrum Team to work closely with customers, users, and other stakeholders. Scrum is a process of ‘collaborative discovery’. Starting only with a rough outline of a treasure map, the Scrum Team goes on a journey with stakeholders to identify where the treasure is actually buried. This collaborative principle is echoed in the third line of the Agile Manifesto: “Customer collaboration over contract negotiation”.
“Scrum is a process of ‘collaborative discovery’”
When only the Product Owner communicates with stakeholders, the following impediments to Agility are likely to arise:
- Stakeholders will not feel heard when the Development Team keeps referring them to the Product Owner to discuss new ideas. By turning Scrum into a bureaucracy, the Scrum Team becomes less responsive to what users need;
- The emergence of new insights, new ideas, and valuable opportunities will be stifled;
- The agility of the Scrum Team diminishes as the Product Owner becomes a bottleneck in clarifying requirements with stakeholders;
- The Development Team will not build the kind of deep understanding of what their users need, resulting in products that are difficult to understand, hard to use and don’t address the actual needs;
So treating the Product Owner as a proxy for stakeholders it not conductive of Agility. But how is the role of the Product Owner intended?
Proxy or facilitator?
Instead of framing the Product Owner as a proxy for stakeholders, we prefer to explain the Product Owner as the person responsible for including the voice of stakeholders in this process of ‘collaborative discovery’. How this is done is up to the Product Owner and the Scrum Team, and depends on the availability of stakeholders and the nature of the product under development. But we’ve seen the following things work well:
- The Product Owner invites stakeholders to attend the Sprint Review, which is a minimal opportunity during Scrum where input from stakeholders is gathered;
- The Product Owner organizes workshops where he/she, stakeholders and members of the Development Team identify and clarify upcoming, valuable work for the product;
- The Product Owner creates opportunities and platforms where the Development Team can work with stakeholders to test assumptions or clarify needs;
- The Product Owner organizes tours or events to help the Development Team to get to know the people that are using the product;
Instead of creating walls around the Development Team, the Product Owner should bridge the organizational gap that often exists between developers and stakeholders (users in particular). In any case, this should be done in ways that are respectful of the focus that the Development Team needs during a Sprint.
”We prefer to explain the Product Owner as the person responsible for including the voice of stakeholders”
We would like to emphasize strongly that the Product Owner remains responsible for what goes on the Product Backlog, and in what order. In every sense of the word, the product is still owned by the Product Owner. But not in bureaucratic, traditional manner where everything has to go through the Product Owner.
Tips
- If you’re the Scrum Master, support your Product Owner by offering formats or approaches to help bridge the gap between development and stakeholders;
- The Liberating Structure ‘25/10 Crowd Sourcing’ is a great way to rapidly identify high-value features with stakeholders and the Development Team. Other Liberating Structures that are very useful here are Wise Crowds and Celebrity Interview;
- Organize sessions where stakeholders and members of the Development Team work together to create ‘Empathy Maps’, ‘Design the Box’ or perform ‘Magic Estimation’;
- Create personas that are based on actual stakeholders and associate them with PBI’s on the Product Backlog. Whenever questions arise during work, the Development Team knows who to contact for further clarification or to validate assumptions;
Closing
In this post, we busted the myth that the Product Owner is the only person on a Scrum Team who talks with stakeholders. The bottom line is that Scrum Teams become significantly less Agile when only the Product Owner is the only person doing this. Instead, we prefer to explain the Product Owner as the person responsible for including stakeholders in the process of collaborative discovery. We offered a few concrete tips on how to do this.
What do you think about this myth? Do you agree? What are your ‘lessons learned’?
