Maybe I’m naive, but I believe that most people mean well. If someone asks for help, most of us are inclined to lend a hand if we can. And that’s great. In theory. But what happens when a Scrum Team becomes overwhelmed with requests that stakeholders make directly to the Developers instead of the Product Owner?
The Product Owner and the Product Backlog
In Scrum, the Product Owner maximizes value from the Scrum Team’s work through their accountability for the content and ordering of the Product Backlog.
The Product Backlog is the list of all planned product improvements and can include bug fixes, production support work, new features and more. Often, the Product Owner is balancing requests from multiple stakeholders, which may appear as items in the Product Backlog, but the Product Owner might say “no” to some stakeholder requests if they don’t align with the overall strategy.
The Product Backlog is more than just a “to-do” list; it is the plan for the team. Its order reflects the Product Owner’s strategy for how the product can best add incremental value to the organization.
What happens if stakeholders bypass the Product Owner?
I can’t overstate the negative impact of direct stakeholder requests on the Scrum Team.
First, if stakeholders bypass the Product Owner and request work directly from Developers, it can lead to the Developers working on lower-priority work while more important work goes unaddressed. Sure, Developers who spend time helping stakeholders are adding value to the organization, but is it the right value? Is it really the most high-value thing that the Developer could be working on? If the Product Owner has not placed a request in the proper order, then the most likely answer is that the Developer is working on lower-priority work.
Second, it can undermine the Product Owner’s authority and responsibilities, leading to confusion and conflict within the Scrum Team and potential duplication of effort if multiple stakeholder requests contradict each other.
Third, it can disrupt workflow and the Developers’ focus on the Sprint Goal. If Developers are constantly pulled away to work on stakeholder requests that are not part of the Product Backlog, it can lead to missed goals and decreased productivity.
Fourth, stakeholder requests mid-Sprint can make it more difficult for the Developers to plan and manage their work, especially if the requests are not added to the Sprint Backlog and made transparent to other Developers on the team. It can lead to Developers having an incomplete or inaccurate understanding of all the work being done during the Sprint.
Finally, going around the Product Owner with requests can lead to a misalignment of expectations between the stakeholders, the Product Owner, and Developers. The Product Owner is responsible for ensuring that the work supports the Product Goal as well as the vision for the product. If stakeholders bypass the Product Owner with work requests, it can lead to a disconnect between the work being done and the larger strategic objectives for the product. Developers can end up running in circles rather than making progress toward the Product Goal.
To ensure that the team focuses on the most important and impactful tasks, stakeholders must take their requests to the Product Owner, who can then work with the team to create a single, ordered Product Backlog. This way, Developers can focus and make progress on the work of the Sprint, ensuring that their work remains in alignment with the Product Goal and product vision.
What can Developers do?
It can be hard for Developers to say no when stakeholders request work directly from them. It’s only natural to want to help, and Developers, in particular, tend to be problem solvers. Here are a few tips that can help when navigating this situation.
Ideally, the team should discuss request management at the Sprint Retrospective. Are there certain types of requests that the Product Owner would like for Developers to accommodate? For example, a simple request for knowledge or production support might be something Developers can handle easily if the request is below a certain size.
If the request from the stakeholder is not something that the Developer can/should accommodate, here are a few tactics for redirecting stakeholders to the Product Owner:
Explain the importance of the Product Owner role and how it’s a critical part of the development process.
Encourage stakeholders to work with the Product Owner. Let them know that the Product Owner is the best point of contact for discussing their needs and requests and that collaboration will ensure that stakeholder priorities align with overall project goals.
Offer to assist with communication. If stakeholders are unsure how to work with the Product Owner, offer to facilitate communication and help them understand the process.
Set boundaries. Let stakeholders know that while you are happy to help, your primary focus is on the work the Product Owner has assigned to the team.
By following these tips, Developers can help to ensure that stakeholders are working effectively with the Product Owner and that the development process runs smoothly.
What can the Product Owner do?
Product Owners can communicate with stakeholders regularly to reinforce that work requests should come to them rather than the Developers. Providing clear guidelines and being responsive to stakeholders’ needs will make the process easier for everyone.
Additionally, the Product Owner can work to build strong relationships with stakeholders and establish themselves as the go-to person for questions and requests related to the product. This can help stakeholders feel comfortable and confident submitting requests through the proper channels.
What can the Scrum Master do?
The Scrum Master can educate stakeholders about the Product Owner’s role and its importance regarding prioritizing and managing requests. The Scrum Master can also help to enforce the process for submitting requests by redirecting any requests that are made directly to Developers back to the Product Owner.
Additionally, the Scrum Master can work with the Product Owner to ensure that the process for submitting requests is clear and easy for stakeholders to follow. This may include creating guidelines for stakeholders to follow or setting up regular opportunities for stakeholders to submit requests and discuss them with the Product Owner.
Conclusion
The Product Owner is accountable for maximizing the product’s value resulting from the Scrum Team’s work. It’s a difficult job and even more challenging when stakeholders bypass the Product Owner and request work directly from Developers, undermining the Product Owners’ authority and disrupting the team’s work. Helping stakeholders understand the Product Owner’s responsibilities and the process for dealing with unplanned work requests can help ensure the product’s success.
To learn more about the Product Owner accountability in Scrum, signup for Rebel Scrum’s upcoming Professional Scrum Product Owner course.
To learn more about how to apply Scrum in your environment, signup for the Scrum Day USA Agile conference, scheduled for September 14, 2023, in Madison, Wisconsin, USA.