The Scrum Guide defines the role of the Product Owner as “responsible for maximizing the value of the product resulting from work of the Development Team”.

There is a lot in that sentence, so let’s break it down. The Product Owner’s purpose is to maximize return on investment by ensuring the Development Team builds the right thing.  This is a huge undertaking and responsibility both to the team and to the business.

The Biggest Anti-pattern

One of the most common Product Owner anti-patterns is wearing multiple hats. This distracts their attention from building the right thing. Building it in the right way is the Dev Team responsibility, and building it fast belongs to the Scrum Master.  

Where is the value in building it the right way or building it fast, if it’s not the right thing to build? The potential impact may lead to loss of customers, decreased revenues or even potential profit losses for the organization.

Looking at the anti-patterns of a Product Owner, it is important to look at it from the perspective of the Scrum Framework and the impact it imposes. Let’s examine the Product Owner anti-patterns from three perspectives: before, after and during the Sprint.

Anti-Patterns: Before the Sprint

Availability of the Product Owner to refine the product backlog

Backlog refinement provides the opportunity for the team to see potential work that is upcoming in the next sprint. Without it, there is an absence of visibility and clearly. planning for the next sprint becomes difficult. Foresight is important. Imagine you’re driving a car, your eyes are on the road immediately in front of you, but occasionally you lookahead to see the upcoming traffic conditions.  

Absence of a shared Definition of Ready and Definition of Done

A Definition of Ready creates a shared understanding of when an item in the backlog is ready to be actionable by the team. The Definition of Done is an agreement between the Product Owner and Dev Team on what it means for a story to be marked as completed.  When either of these artifacts is missing, there can be a lack of shared understanding within the team. This creates conflict where teams are unable to commit to backlog items, or stories are completed with varying degrees of quality.

Product Backlog - a dumping ground for ideas  

A healthy backlog contains a prioritized backlog of stories, ideally enough for one or two sprints, which allows stakeholders including the Dev Team to visualize their focus. An ideal backlog will be layered like lasagna, easy to navigate and transparent. Not tangled like spaghetti, making it difficult to find things and leading to confusion around what needs to be done. To better manage transparency and visibility, potential ideas should not be dumped into the backlog. Manage a separate backlog for potential work.

Not defining the Sprint Goal

A Sprint goal is a team objective for the sprint. It can be accomplished through completion of a set of product backlog items.  A Sprint Goal helps teams focus on outcomes and can be used as an instrument to engage and communicate with stakeholders. A sprint goal is a foundational piece that helps support product backlog prioritization.

Anti-Patterns: During the Sprint

Adjusts the Sprint Backlog mid-Sprint without team input

As stated above, the Sprint Backlog outlines the team’s commitment for the sprint. By continuously adding to the Sprint Backlog, without work being sized or estimated by the team, it defeats the purpose of asking the team for commitment in the first place. It also raises the question of how well the backlog was originally prioritized and typically leads to a team becoming cautious in sprint planning.

Skipping every Daily Stand-up or not being available during the Sprint

When the Product Owner is not able to attend the Daily Stand-up throughout the Sprint, the visibility of progressing towards the Sprint Goal disappears, and the backlog is no longer up to date. It also removes the Dev Team’s opportunity to seek clarifications from the Product Owner, which also may impede story completion.  The Daily Stand-up provides visibility to the Product Owner for completed stories, which can be inspected to ensure the Definition of Done is met. Otherwise, incomplete stories are rejected at Sprint Review with late feedback and no time to address the discrepancies.

Leads the Sprint Review

As per the Scrum Guide, the Dev Team should attend the Sprint Review and have their moment in the limelight to demonstrate their hard work. The Product Owner should not take centre stage to showcase the product increment. Product Owner focus during the Sprint Review should shift away from demonstrating and setting the context for the stakeholders, the goal of sprint, the accomplishment and the overall progress.

Not engaging stakeholders in Sprint Review or abandoning the Sprint Review  

Sprint Review provides a window of opportunity to showcase progress. When stakeholders are not engaged, they will often use status reports as an alternative.  When progress is not visible, focus centers on vanity metrics like velocity. Abandoning the Sprint Review for the sake of preserving time diminishes the value and importance of the review.  

Commitments made during the Sprint Review from stakeholder’s feedback

Naturally Product Owners want to please their stakeholders, but at what cost? At the Sprint Review stakeholders can be eager to provide feedback on what they would like to see added. But remember that the Sprint Review’s purpose is not for promises to be made, but instead an opportunity to showcase what the team has completed and welcome feedback for consideration. The promise of adding additional features in the Sprint Review creates additional pressure for delivery and unrealistic stakeholder expectations. This is often referred to as backlog explosion.

Anti-Patterns: After the Sprint

Absence from the retrospective

The Retrospective plays a key role in the inspect and adapt cycle and provides the Product Owner the opportunity to collaborate with the Dev Team to improve the process. By not attending the retrospective, the Product Owner loses the opportunity to understand what may be impeding the team, which may be the Product Owner themselves. A retrospective without a Product Owner is like playing soccer without a goalkeeper... not going to get very far!  

Focusing on burn down charts over product burn up

While burn down charts are important to measure how the team is progressing towards the Sprint Goal, a burn up charts provide a more holistic picture and reveals how much the team may be able to complete for the release. These insights will drive decisions on how to manage and prioritize the remaining backlog items. Without this foresight, it creates more challenging conversations between the Product Owner and their stakeholders.

Not thanking the team and not celebrating

Like any sports team, the team succeeds together and fails together. Recognition in the form of a thank you can help drive a team forward. Without this, the team is just a group of individuals working on the same thing. Shared successes help created tighter bonds, that can lead to a high performing team.

What anti-patterns do you see in your Product Owner? It's important to realize and act upon them, to keep your team functioning smoothly.