Product Owner Anti-Patterns — 31+2 Ways to Improve as a PO

TL; DR: Scrum Product Owner Anti-Patterns

If you are working as a Product Owner, there is — very likely — room for improvement. This list of some of the most common Product Owner anti-patterns might be a starting point. Hence, if you recognize some anti-patterns in your daily work, why don’t you ask the rest of the Scrum Team for support? The Product Owner anti-patterns list is a good starting point for a retrospective.

Do you want to get this article in your inbox? You can sign up here and join 25k other subscribers.

The Role of the Product Owner According to the Scrum Guide

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” The primary way of achieving this goal as a PO is the management of the Product Backlog. According to the Scrum Guide, this activity comprises:

? 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; and,

? Ensuring the Development Team understands items in the Product Backlog to the level needed.

Source: Scrum Guide 2017.

In my experience, most Product Owner anti-patterns result from a less than adequate handling of this Product Backlog management task.

Product Backlog and Refinement Anti-Patterns

You can spot most of the Product Owner anti-patterns in the PO’s backyard — the Product Backlog and its refinement:

• Storage for ideas: The Product Owner is using the Product Backlog as a repository of ideas and requirements. (This practice is clogging the Product Backlog, may lead to cognitive overload and makes alignment with the ‘big picture’ at portfolio management and roadmap planning level very tough.)
• Part-time PO: The Product Owner is not working daily on the Product Backlog. (The Product Backlog needs to represent at any given time the best use of the Development Team’s resources. Updating it once a week before the next refinement session does not suffice to meet this requirement.)
• Copy & paste PO: The Product Owner creates user stories by breaking down requirement documents received from stakeholders into smaller chunks. (That scenario helped to coin the nickname “ticket monkey” for the product owner. Remember: user story creation is a team exercise.)
• Dominant PO: The Product Owner creates user stories by providing not just the ‘why’ but also the ‘how’, and the ‘what’. (The team answers the ‘how’ question — the technical implementation –, and both the team and the PO collaborate on the ‘what’ question: what scope is necessary to achieve the desired purpose.)
• Prioritization by proxy: A single stakeholder or a committee of stakeholder prioritize the Product Backlog. (The strength of Scrum is building on the strong position of the Product Owner. The PO is the only person to decide what tasks become Product Backlog items. Hence, the Product Owner also decides on the priority. Take away that empowerment, and Scrum turns into a pretty robust waterfall 2.0 process.)
• 100% in advance: The Scrum Team creates a Product Backlog covering the complete project or product upfront because the scope of the release is limited. (Question: how can you be sure to know today what to deliver in six months from now?)
• Over-sized: The Product Backlog contains more items than the Scrum Team can deliver within three to four sprints. (This way the Product Owner creates waste by hoarding issues that might never materialize.)
• Outdated issues: The Product Backlog contains items that haven’t been touched for six to eight weeks or more. (That is typically the length of two to four sprints. If the Product Owner is hoarding backlog items, the risk emerges that older items become outdated, thus rendering previously invested work of the Scrum Team obsolete.)
• Everything is estimated: All user stories of the Product Backlog are detailed and estimated. (That is too much upfront work and bears the risk of misallocating the Scrum Team’s time.)
• Component-based items: The Product Backlog items are sliced horizontally based on components instead of vertically based on end-to-end features. (This may be either caused by your organizational structure. Then move to cross-functional teams to improve the team’s ability to deliver. Otherwise, the team — and the Product Owner — need a workshop on writing user stories.)
• Missing acceptance criteria: There are user stories in the Product Backlog without acceptance criteria. (It is not necessary to have acceptance criteria at the beginning of the refinement cycle although they would make the task much easier. In the end, however, all user stories need to meet the definition of ready standard, and acceptance criteria are a part of that definition.)
• No more than a title: The Product Backlog contains user stories that comprise of little more than a title. (See above.)
• Issues too detailed: The Product Owner invests too much time upfront in user stories making them too detailed. (If a user story looks complete, the team members might not see the necessity to get involved in further refinement. This way a “fat” user story reduces the engagement level of the team, compromising the creation of a shared understanding. By the way, this didn’t happen back in the days when we used index cards given their physical limitation.)
• Neither themes nor epics: The Product Backlog is not structured by themes or epics. (This makes it hard to align individual items with the “big picture” of the organization. The Product Backlog is not supposed to be an assortment of isolated tasks or a large to-do-list.)
• No research: The Product Backlog contains few to no spikes. (This often correlates with a team that is spending too much time on discussing prospective problems, instead of researching them with a spike as a part of an iterative user story creation process.)
• What team? The Product Owner is not involving the entire Scrum Team in the refinement process and instead is relying on just the “lead engineer” (or any other member of the team independently of the others).

Sprint Planning Anti-Patterns

The number two area on my list of product owner anti-patterns is the sprint planning itself:

• What are we fighting for? The Product Owner cannot align the business objective of the upcoming Sprint with the overall product vision. (A serious goal answers the “What are we fighting for?” question. To a certain extent, it is also a negotiation between the Product Owner and the Development Team. It is focused and measurable, as the Sprint goal — based on the business objective — and Development Team’s forecast go hand in hand.)
• No business objective, no Sprint Goal: The Product Owner proposes Product Backlog items that resemble a random assortment of tasks, providing no cohesion. Consequently, the Scrum Team does not create a Sprint goal. (If this is the natural way of finishing your Sprint Planning, you probably have outlived the usefulness of Scrum as a product development framework. Depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak Product Owner who listens too much to stakeholders instead of ordering the Product Backlog appropriately.)
• Unfinished business: Unfinished user stories and other tasks from the last Sprint spill over into the new Sprint without any discussion. (There might be good reasons for that, for example, a task’s value has not changed. It should not be an automatism, though, remember the sunk cost fallacy.)
• Last-minute changes: The Product Owner tries to squeeze in some last-minute Product Backlog items that are not ready yet. (Principally, it is the prerogative of the Product Owner to make such kind of changes to ensure that the Development Team is working only on the most valuable tasks at any given time. However, if the Scrum Team is otherwise practicing Product Backlog refinement sessions regularly, these occurrences should be a rare exception. If those happen frequently, it indicates that the Product Owner needs help with ordering the Product backlog and team communication. Or the Product Owner needs support to say ‘no’ more often to stakeholders.)
• Output focus: The Product Owner pushes the Development Team to take on more tasks than it could realistically handle. Probably, the Product Owner is referring to former team metrics such as velocity to support his or her desire. (This is also a road to becoming a feature factory and deserves attention from the team’s Scrum Master. It is violating the Development Team’s prerogative to pick Product Backlog item for the Sprint Backlog as well as Scrum Values.)
• No preparation: The Product Owner does not prepare the Product Backlog to provide useful Product Backlog items for selection by the Development Team. (Product Backlog needs to represent the best possible use of the Development Team’s work from a customer value perspective at any given moment. In other words, your Scrum Team’s Product Backlog has to be actionable 24/7. By my standards, that means that you need to be capable of running a meaningful Sprint Planning instantly. Preparing a few basic Product Backlog items an hour before the beginning of the Sprint Planning is not enough.)

Sprint Anti-Patterns

Another area prone to Product Owner anti-patterns is the sprint itself:

• Absent PO: The Product Owner is absent most of the Sprint and is not available to answer questions of the Development Team. (As the Sprint Backlog is emergent and new work may be identified as necessary to achieve the Sprint Goal, this attitude might leave the Development Team in the dark, risking the accomplishment of the Sprint Goal.)
• PO clinging to tasks: The Product Owner cannot let go Product Backlog items once they become part of the Sprint Backlog. For example, the Product Owner increases the scope of a requirement. Or, he or she changes acceptance criteria once the team accepted the issue into the Sprint Backlog. (There is a clear line: before a Product Backlog item turns into a part of the Sprint Backlog, the Product Owner is responsible. However, once it moves from one backlog to the other, the Development Team becomes responsible. If changes become acute during the Sprint the team will collaboratively decide on how to handle them.)
• Inflexible PO: The Product Owner is not flexible to adjust acceptance criteria. (If the work on a task reveals that the agreed-upon acceptance criteria are no longer achievable or waste, the Scrum Team needs to adapt to the new reality. Blindly following the original plan violates core Scrum principles.)
• Delaying PO: The Product Owner does not accept items from the Sprint Backlog once those are finished. Instead, he or she waits until the end of the Sprint. (The Product Owner should immediately check tasks that meet the acceptance criteria. Otherwise, the Product Owner will create an artificial queue within the Sprint, which will unnecessarily increase the cycle-time. This habit puts also reaching the Sprint Goal at risk.)
• Misuse of Sprint cancellation: The Product Owner cancels Sprints to impose his or her will onto the team. (It is the prerogative of the Product Owner to cancel Sprints. However, the Product Owner should not do this without a serious cause. The Product Owner should also never abort a Sprint without consulting the Development Team first. Probably, the team has an idea of how to save the sprint. Lastly, misusing the cancellation privilege also indicates a serious team collaboration issue.)
• No Sprint cancellation: The Product Owner does not cancel a Sprint whose sprint goal can no longer be achieved. (If the Product Owner identified a unifying Sprint Goal, for example, integrating a new payment method, and the management then abandons that payment method mid-sprint, continuing working on the Sprint Goal would be a waste. In this case, the Product Owner should consider canceling the sprint.)

PO Anti-Patterns during the Daily Scrum

By comparison to other Scrum events, the Daily Scrum is remarkably resilient to Product Owner anti-patterns:

• Planning meeting: The PO hijacks the Daily Scrum to discuss new requirements, to refine user stories, or to have a sort of micro (Sprint) planning meeting.
• The talkative PO: The Product Owner actively participate in the Daily Scrum. (POs and Stakeholders are supposed to listen in but not distract the Development Team members during their inspection and adaptation.)

Sprint Review Anti-Patterns

Finally, there is the Sprint Review. Despite that it is an outstanding opportunity for the Product Owner to improve the collaboration with both stakeholders and the Development Team and figure out collectively in what direction to take the product next, some Product Owners do not get the message:

• Selfish PO: The Product Owner presents “his or her” accomplishments to the stakeholders. (Remember the old saying: There is no “I” in “team?”)
• “Acceptance” by the PO: The Product Owner uses the Sprint Review to “accept” tasks/Product Backlog items. (An alignment — did the Development Team deliver the required functionality? — is useful and should be decoupled from the Sprint Review. The Product Owner should communicate with the Development Team when issues meet acceptance criteria.)
• Unapproachable PO: The Product Owner is not accepting feedback from stakeholders or the Development Team. (Such behavior violates the prime purpose of the Sprint Review event.)

The Youtube Playlist of the Webinar Product Owner Anti-Patterns Is Available

The videos of the webinar are available now:

Note: If the browser will not play the playlist automatically, click here to watch the Webinar Product Owner Anti-Patterns playlist directly on Youtube.

Conclusion

Admittedly, the Product Owner role is the most challenging Scrum role, and the higher the expectations are, the easier it is to fail them. Nevertheless, the concept of continuous improvement also applies to the Product Owner role. The list of Product Owner anti-patterns above may be a starting point.

What Product Owner anti-patterns have you observed that are missing in the list? Please share with us in the comments.

The Product Owner Anti-Patterns — Related Posts

28 Product Backlog and Refinement Anti-Patterns

Liberating Structures for Scrum (3): The Product Backlog

Download the ’Scrum Anti-Patterns Guide’ for Free

? Do Not Miss Out: Join the 6,700-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Communityand enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

?? Do You Want to Read more like this?

Well, then:

• ?? Join 25,021 peers and sign-up for my weekly newsletter
• ?? Follow me on Twitter and subscribe to my blog Age of Product
• ?? Alternatively, join 6,700-plus peers of the Slack team “Hands-on Agile” for free.

Product Owner Anti-Patterns — 31+2 Ways to Improve as a POwas first published on Age-of-Product.com.