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.    

Product Roadmap | 5 Challenges of Product Scrum Owners 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.

Work with our Agile Experts - Discover our Development Services

5 tips to triage your software release backlog

It’s often difficult for software development teams to effectively prioritize their workloads. The requests for changes and new features come thick and fast in most enterprise organizations. Every department wants top priority as they fight for their own client projects, but the development team has a limited capacity to deliver.

When developers are in firefighting mode, constantly being asked to change gears and take on new tasks, efficiency plummets. The path to clearing the backlog lies through proper planning, a system of prioritization, and a clear roadmap that provides stability and predictability. A time box release model will deliver benefits for IT, business, and the clients.

Set up time box releases

Fixing release dates immediately introduces some stability into your process. It also allows different business groups to reliably predict when new features and change requests are going to be rolled out. Everybody hates it when release dates slip, but a time box release cycle can alleviate this. Finding the right cycle for your team will depend on the project, but somewhere between four and eight weeks is a good place to start.

A fixed period for each cycle allows development to calculate exactly how much they can get done with their current resources. The cycles can be reduced over time. Different companies and projects will want different cycle lengths. The important thing is to have a fixed date for each release.

Prioritize the requests

Triage is all about sorting the incoming requests and ensuring that the highest priority ones are dealt with first. Get your business groups to rank their requests, based on how important they are to the client. They should each submit a limited list of their top ten or 20 ranked requests. Set a deadline for submission a week or two before the cycle begins.

Everyone should get round the table to slot requests into the release backlog. The scrum master, the product owner, the developers, and QA need to put their heads together to assess the request and estimate how to deliver it.

Lock the cycle down

When the cycle has been drawn up and signed off it should be locked down. If any business group wants to change a request or submit something new, they must be aware that it won’t be considered until the next cycle. Failure to apply this rule will make it impossible for the current crop of priorities to be delivered on time.

Build in a contingency

There will occasionally be a genuine emergency that has to be accommodated, so always build in some contingency. Saving 10% to 15% of capacity to deal with an important client demand or a special emergency case is sensible, but be sure to establish urgency before accepting a new request.

Plan for the future

Once everyone is used to the new system and priorities are being regularly delivered for every cycle as promised, business groups and their clients will feel the benefits. It may be possible to plan further ahead and create a roadmap that stretches six months or a year into the future. Fixing release dates and project submission deadlines can really help improve efficiency.

Setting a realistic plan and a methodical approach to clearing that software release backlog is the best way forward for everyone concerned.

Looking for a new software development partner?