A good product owner should be collaborative, responsible, authorized, committed, and knowledgeable. But what do you do if yours doesn’t exemplify these characteristics? This article aims to showcase mitigation plans that can be effective for overcoming Scrum violations due to the fact that you’re not working with a typical product owner.
In an onsite-offshore project development model, the development team, ScrumMaster, and project management team typically live in another country, whereas the product owners and product management team work onsite. When India is considered the “offshore” and the US is “onsite,” there are lots of challenges with following Scrum.
One of my company’s customers finds it difficult to follow Scrum as it is detailed in the Scrum Guide. For example, this customer cannot bear the cost of having a dedicated product owner, so a few individuals who are experienced and knowledgeable about the product have been assigned to work in the capacity of the product owner. They are the point of contact for the offshore development team for any requirement clarification or prioritization. However, these people are primarily full-time tier-2 technical support team members. In other words, the development team does not have a dedicated product owner available to answer questions all the time.
One impact of this is that the people acting as the product owner do not create user stories. Instead they send high-level requirements, much like epics or themes. Another impact is that final authority for making decisions about requirements and prioritization does not belong to the product owner, but rather to the product owner’s reporting manager.
A good product owner should be CRACK—an acronym standing for collaborative, responsible, authorized, committed, and knowledgeable.
But what do you do if your product owner doesn’t exemplify these characteristics? This article aims to showcase mitigation plans that can be effective for overcoming Scrum violations due to the fact that you’re not working with a typical product owner.
When Your Product Owner Is Not Collaborative
Addressing the first letter of CRACK, the people in this example of a product owner are not collaborative. They do not work with stakeholders for requirement clarification or communicate to the team. They assign a backlog, which is mostly one-liner requirements or epics, and are not accessible thereafter to the team. The usual format of requirement gathering goes like this: The development team asks questions and voices doubts, and the product owner clarifies (if he or she knows the answer) or gets clarification from a concerned stakeholder and discusses the results with the development team in the next meeting. It delays decision-making and keeps the development team waiting.
My team has been able to take some actions to mitigate this lack of collaboration. We conduct a joint workshop where all the important stakeholders are available for discussion and clarification. We plan this session to discover and stop maximum doubts and clarification and hold the session just before the release plan meeting.
The ScrumMaster makes sure this meeting happens with the right stakeholders and helps the product owners organize discussions with different stakeholders to ensure that only those changes are added in the backlog. These backlog items are added with sufficient details so they represent maximum ROI.
When Your Product Owner Is Not Responsible
When your product owner is not responsible, it’s serious and has significant negative impacts. To help manage this challenge, we keep the product manager in requirement workshop meetings along with other product owners and stakeholders so that all the major decisions can be reviewed in the workshop. We also involve the product owner in design reviews and schedule regular working software demos apart from the iteration review. The regular demo is usually only with the product owner and product manager.
When Your Product Owner Is Not Authorized to Decide
It’s difficult when the product owner is not authorized and empowered to make decisions. The product owner has to get final approval from the product manager, and that person has the power to overrule the original decision. It results in rework, delays in making decisions, and ranking the backlog.
My team convinced the stakeholders to increase the release duration from ten weeks to fourteen weeks. This gave the product owner more time to discuss with product manager about requirements, priorities, and getting final approval before communicating changes to development team.
Because the ScrumMaster and product owners are domain experts, they jointly own the product ROI decision. Due to this collaboration, the product manager's chances to overrule a decision are reduced. It seems democratic and very effective for my project.
When Your Product Owner Is Not Committed
When the product owner does not have enough time for the development team due to multiple role assignments, there are multiple action points to mitigate.
My team schedules a recurrent overlapping discussion during a live meeting with the product owner. All team development members are invited, but only those who need to participate in a discussion with product owner joins the meeting. If people don’t need to discuss anything, they continue working. This ensures the development team doesn’t increase their delay. If the product owner goes on leave or is not available for the meeting, he assigns some other product owner who can provide input to the team.
The ScrumMaster makes sure the meeting happens and team members are not waiting more than a day for any input.
When Your Product Owner Is Not Knowledgeable
What happens when the product owner is not knowledgeable about domain, user experience, market trends, or the right technology? This problem mostly results in lower ROI.
Risk from this problem can be mitigated by involving all product owners from the pool, ScrumMasters on different teams, and the originators of change requests in a requirement workshop. This workshop is iteration 0, which goes for four to five days in every release. Our release cycle schedule varies from three to four months. In this workshop we discuss all requirements planned in the release. This workshop is detailed enough to be agreeable to the development team and focuses on setting the right priority on epics.
Product owners who can only dedicate themselves part time to the role are a risk for any project, but this situation can be a reality for some organizations. My team has mitigated this risk to a good extent, and our experiences can help mitigate the project risk for other teams in this position.
