5 Challenges of Scrum Product Owners and How to Solve Them
Scrum Product Owners are key roles in a software development effort. They develop the product roadmap in terms of what features to build, when to build them, and in which order to build them. According to Scrum.org, Scrum Product Owner is the sole person responsible for managing Product Backlog with primary activities below:
- Clearly expressing Product Backlog items.
- Ordering the items in the Product Backlog to best achieve goals and missions.
- Optimizing the value of the work the Development Team performs.
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
Though these activities seem to be straight forward, Product Owners often face challenges that jeopardize the productivity of the whole scrum team, and risk impacting the return on investment being made to build or update the product.
This article outlines top 5 challenges that Scrum Product Owners typical encounter and how to solve them.
Do you have a product roadmap?
If your answer is yes, then congratulations! You are likely on the right track. If you do not have a product roadmap, then you and your team are likely developing product features driven by customer requests, rather than based on a strategic plan or vision for the product. While it’s extremely important to actively listen and be responsive to your customer needs, this puts your product at risk of becoming overly customized to a specific group of “noisy” customers, and may not serve the needs of your current and future customer base.
To address this challenge, Product Owners should develop product a roadmap based on market research, industry standards, and best practices instead of building product features solely from a client’s customization requests. The product roadmap should be revised frequently and make it known to both external and internal stakeholders. It is a check and balance tool to align the team and customer focus on building long term value products.
Not all user stories have equal values
Have you come across the situation in which your stakeholders indicate that user stories A, B, C work but complain that user story D did not work and was not defined? It then turns out that the said story is an edge case. This dilemma also applies to bug fixes or product backlog items in general.
The real challenge here is landing on appropriate priority of each product backlog item, and basing that priority on the amount of positive impact it can have on the broadest set of customers. Focusing on “edge cases” can take away valuable development cycles on low impact features, that only benefit a small subset of users, occur infrequently, or have an acceptable work around in place.
To alleviate the challenge, it is recommended that Product Owners define a process to triage and prioritize backlog items. Specifically, Product Owners should research on usage volume of the user story, what value it would add to the business, and how broad it can apply to the customer base. Product Owners should also triage bugs to know how likely the bug will occur, and how severe it is or if there is a workaround solution. Product Owners then assign a value to each backlog item, then stack rank the backlog with highest value item on top. This will ensure the Scrum team spends effort on the most value item first.
Vague acceptance criteria, or too rigid details, can kill innovation
User stories without crisp acceptance criteria leave too much room for interpretation which leads to scope creep and eventually requires rework. On the other hand, acceptance criteria with too rigid details would discourage innovative solutions from the scrum team who then become order-takers.
Finding a right balance from both ends is an art that Product Owners should aim to achieve. To ensure product backlog items have good quality, Product Owners should follow INVEST best practice created by Bill Wake. INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. Jim Bowes published an article on Manifesto UK “How Much Details a User Story Should Have” in which he pointed out that a user story with too much detail shuts down conversations and that developers may think that all questions around the feature have been settled, therefore there is little room left for negotiation.
In addition, Product Owners should avoid grooming the backlog items in silos. Instead, Product Owner should inspect and adapt product backlog items frequently by reviewing them with the scrum team, and with end users. Through the review process, Product Owners can state the user story’s goal and encourage the team to bring their ideas to the table where the team will collectively agree on the one that would yield the most value.
Product backlog items with ambiguous acceptance criteria are icebergs of which the hidden negative effect is enormous.
Spending too much time in dealing with product support instead of grooming the backlog
Product backlog items with ambiguous acceptance criteria are icebergs of which the hidden negative effect is enormous and will slowly drown the Product Owners. Given that a user story’s goal and acceptance criteria are too loosely defined, stakeholders are free to translate it with their own perspective. The scrum team would develop the user story that is far deviated from the end user’s expectation. Documentation and training of the new user story may have further deviation from the original goal. Sales teams would promote the product from how they believe it would work instead of current product behavior. Customer support, tier 3, and end users would also have their own understanding on how the feature should work. Product Owners would eventually spend more and more time to explain what the feature is intended for, clear the confusion, and define corrective actions, instead of grooming the product backlog. The cycle will repeat and Product Owners would have less time to put more quality in product backlog grooming activities.
This problem is easier to prevent than to fix. Simply put, investing more time up front in grooming quality product backlog items following the INVEST principle would prevent this issue down the line.
Changing priority while sprint is in progress
One of the Agile principles is to welcome change, even late in development. If not managed appropriately, however, change can be detrimental to the team’s ability to deliver what has been promised to the customer. Interruptions caused by introducing changes during a sprint cycle negatively impact the team’s velocity, and potentially the quality of deliverables due to context switching. Therefore, Product Owners should resist interrupting the sprints and limit it to only certain circumstances.
In business environments where changes happen rather frequently, the scrum team should consider shortening the sprint duration to avoid this issue. The sprint duration should be planned according to the stakeholder’s tolerance of average wait time and how often the change requests are expected. Setting clear expectations with stakeholders around the timeframe to bring changes to the team will enable velocity to remain constant from sprint to sprint, and keep the scrum team focused on delivering quality work during each sprint cycle.
In summary, Product Owners can avoid these 5 typical pitfalls by defining product roadmap, focusing on high-value backlog items, defining crisp acceptance criteria, focusing on grooming quality backlog item, and avoiding interrupting sprints. At the end, our ultimate goal is to satisfy the customer through early and continuous delivery of valuable software.
