Agile ‘Sins’: How to avoid these 5 product owner anti-patterns in Scrum?

The product owner in a scrum team is the voice of the customer, entrusted with the responsibility of maximizing business value by carefully formulating, prioritizing, and communicating requirements with relevant inputs from stakeholders. However, the guidelines of scrum around the product owner are often bypassed. Instead counter-productive workarounds are put into place, which bring us to anti-patterns when dealing with product owners. Such anti-patterns are common and widespread in the software development world, especially in traditional fixed-bid contracts and in scenarios where the product owner is from the customer organization while the development team is an Independent Software Vendor (ISV).

Following are 5 common anti-patterns with examples and quick tips to avoid them:

Anti-pattern 1: The missing product owner

Product owners work closely with business stakeholders and are placed high in the hierarchy. The role of a product owner is often one of many others they are required to play. So, their absence from sprint events is 'understandable' and 'accepted'. The real impact is that of incorrect implementation leading to wastage, no acceptance till late into the delivery cycle which increases the cost to correct and the lost opportunity for team collaboration.

A common response is to bring in a proxy product owner who has little or no business knowledge. This results in poor work prioritization, incorrect development of the solution, and loss of opportunities to collaborate with the development team.

The suggested solution in such a scenario would be to coach the product owner (or the proxy) to reiterate the importance of the role and benefits that his/her availability brings. Conversations with data and specific examples always work better than generalized statements. If coaching is unlikely to work, having a proper mechanism in place facilitates the assistance from the product owner’s organization. As a last resort, tie the obligations of the Product Owner into the contract (for future engagements) or the operation level agreement, as the case may be.

Anti-pattern 2: Unclear requirements before the sprint starts

Requirements that a product owner would like the team to pick up next are discussed during the sprint planning meeting to a point where everybody is clear on what needs to get done. The development team decides how many and how much of the requirements it can deliver. What happens when there aren’t enough requirements ready to discuss with the development team during the sprint planning meeting? Imagine a vague requirement description such as – the report page should be usable. This could be interpreted in many ways and the complexity could vary, based on the original intent of the requirement.

One option would be to accept the situation and start development with some requirements in a half-baked state. The result is wasted effort and re-work when the requirements are finally detailed and communicated. Besides productivity, team morale takes a hit. It is something similar to trying to hit the bulls-eye on a violently moving dartboard with your performance being judged on it.

The aim should be to always maintain a healthy backlog of items. If the product owner is busy, work alongside and co-create the requirements. Setup special backlog grooming meetings for maintaining a healthy backlog for the upcoming sprint.

Anti-pattern 3: No formal acceptance till the UAT phase

Sprint review meetings are rarely attended by relevant stakeholders. They either skip or don’t come prepared to review and accept what has been delivered. Since all projects have a UAT or at least a stabilization phase, it is assumed the real acceptance should happen only during the UAT phase. This effectively means the formal acceptance of all the requirements is queued up for the UAT phase, leading to a waterfall delivery kind of a situation where everything hinges on the feedback during the UAT phase, which typically is delayed in the delivery cycle. Due to the time lag between the development sprint and the start of the UAT phase, (besides other risks) there can be a considerable loss of knowledge on the part of business and IT.

A formal acceptance process should be put in place for partial acceptance of the requirements delivered at the end of each sprint. An approach that works well is to automate the acceptance tests during the development phase, with the customer signing off on the acceptance tests.

Anti-pattern 4: Product owner not reaching out to the users or the business community

What happens in a scenario where the product owner doesn’t collaborate or keep key stakeholders in the loop? They may often believe that it is not important to do so because they have been in the business long enough. Overlooking this issue is often a response from the development team as its objective is to  keep the product owner satisfied. But why should one care?

The development team needs to deliver the solution that meets the client’s vision for the product. If the product owner acts in isolation and isn’t aligned with the organization’s vision, it is a matter of time before problems begin to surface. As a simple example, imagine a product owner adding a product offering on a telecom company’s website when the organization may have recently decided to mark that product as the end of life.

The right approach would be to raise a concern with the customer organization through an agreed-upon mechanism, usually to an Executive Steering Group. The escalation framework is usually agreed upon and tied into the contract.

Anti-pattern 5: No backlog prioritization

Why should one prioritize when it is a fixed bid contract and the scope is locked in?

The scope is never locked in, even in a fixed bid contract. There is always a set of requirements that contribute to the Minimum Viable Product (MVP) and then there are requirements that should be there but are not critical. As an unsaid rule, requirements will evolve over time. E.g., for an e-commerce site, having the team work on a reporting module before core modules such as the shopping cart.

Thus, it is crucial to ensure requirements get prioritized in a manner that the Minimum Viable Product(MVP) is in place, before work begins on the non-critical requirements. Remember, the product owner bears the responsibility for maximizing the return on investment.

There are various techniques available to help prioritize the product backlog which we bring forth in our training program for Product Owners.

There are more anti-patterns that you as a product owner or someone working with one may come across while working towards a delivery. Nagarro's heartbeat offering in the agile consulting space helps identify such anti-patterns and provide guidance on correcting them. For more detailed discussion on our agile offerings, feel free to reach us at info@nagarro.com.