Product Owner Anti-Patterns

TL; DR: Product Owner Anti-Patterns

No other role in Scrum can contribute to mediocre outcomes like the Product Owner—garbage in, garbage out—and it does not matter whether that’s due to incompetence, neglect, disinterest, or failure to collaborate. Moreover, no Product Owner is the “Mini-CEO” of the product, entitled to make lone decisions. Scrum is a team sport; there are no loners in a successful Scrum Team where collaboration and alignment are prerequisites for success.

A Product Owner prone to making lone decisions is in danger of loving their solution over the customers’ problems. Consequently, collaborating and aligning with their teammates on the Product Goal and the Product Backlog is a proven risk-mitigation strategy for Product Owners. This is a testament to Scrum’s built-in checks and balances, particularly now that the product operating model receives more attention.

The Role of the Product Owner According to the Scrum Guide

The Scrum Guide characterizes the job of the Product Owner as follows:

• Maximizing the product’s value from the Scrum Team’s work.
• Developing and explicitly communicating the Product Goal.
• Managing the Product Backlog, including delegating responsibilities while remaining accountable.
• Communicating with stakeholders and representing the needs in the Product Backlog through direct communication or Scrum events such as the Sprint Review.
• Ensuring the Product Backlog is transparent, visible, and understood.
• Ordering Product Backlog items.
• Defining business objectives for Sprints.
• Canceling Sprints if a Sprint Goal becomes obsolete.

Most Product Owner anti-patterns result from misunderstanding the Product Backlog management aspect at the heart of the Product Owner’s responsibilities. Notably, less successful Product Owners fail to communicate with teammates and stakeholders. Maximizing the value of the Scrum Team’s work from a customer perspective while contributing to the organization’s bottom line within the given constraints is less a question of project management skills, juggling with product requirement documents, or keeping the Jira up-to-date.

Consequently, successful Product Owners spend less time handling the Product Backlog than they allocate to product discovery in general and creating alignment among all players in particular. To them, the Product Backlog is a means to an end, not the purpose of their existence.

Instead, successful Product Owners spend time creating a transparent system that allows them to identify potentially valuable ideas from all sources, relentlessly communicating the “Why” and collaborating with the Developers on the “What.”

Learn more: Scrum Guide 2020.

Product Backlog and Refinement Anti-Patterns

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

• Storage for ideas: The Product Owner uses the Product Backlog as a repository of ideas and requirements. (A large Product Backlog is probably considered a sign of a “good” Scrum team: You are fully transparent, and this is proof of your usefulness to the organization. However, being “busy” does not equal value to customers and the organization. The additional noise created by the sheer number of issues may also cloud the detection of valuable items. Lastly, the Product Backlog size may have a crowding-out effect on stakeholders as they feel overwhelmed. The idea-inflated Product Backlog may impede critical communication with them as a consequence.)
• Part-time PO: The Product Owner is not working daily on the product backlog. (The Product Backlog needs to represent the best use of the Developers’ time at any given time. Suppose an update to the Product Backlog happens only occasionally, for example, shortly before the next Sprint Planning. Due to a lack of refinement, it is likely to leave a lot of value on the table. The value of the Product Backlog results in a significant part from the open discussion between the Product Owner and the Developers. In a good Scrum team, the Developers constantly challenge the Product Owner regarding the value of suggested Product Backlog items. This checks & balances approach reduces the probability of the Product Owner falling victim to confirmation bias, thus mitigating the risk that the Scrum team makes a wrong investment decision in the next Sprint Planning. As the saying goes: Love the customers’ problem, not your solution.)

• Copy & paste PO: The Product Owner creates Product Backlog items 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: Refining Product Backlog items is a team exercise. Moreover, using practices like user stories templates helps everyone understand the Why, the What, and the How. Remember Karl Popper: “Always remember that it is impossible to speak in such a way that you cannot be misunderstood.”) 
  
   

  

• Dominant PO: The Product Owner creates Product Backlog items by providing not just the ‘Why’ but also the ‘How’ and the ‘What.’ (Just stick with the Scrum Guide and its built-in checks & balances: The Developers answer the ‘How’ question–the technical implementation–, and both the team and the Product Owner collaborate on the ‘What’ question: What scope is necessary to achieve the desired purpose?)
• Prioritization by proxy: A single stakeholder or a committee of stakeholders prioritizes the Product Backlog. (The strength of Scrum is building on the solid position of the Product Owner. The Product Owner is the only person to decide what tasks become Product Backlog items. Hence, the Product Owner also decides on ordering the Product Backlog. Take away that empowerment, and Scrum turns into a pretty powerful waterfall 2.0 process.)
• 100% in advance: The Scrum team creates a Product Backlog covering the complete project or product upfront because the release scope is believed to be limited. (Let me ask a question: How can you be sure to know today what to deliver six months from now when you work on a complex, adaptive problem? Isn’t not being able to predict the future the reason that you employ Scrum in the first place?)
• Over-sized: The Product Backlog contains more items than the Scrum team can deliver within three to six sprints. (This practice very likely will result in wasted efforts: You will refine work items that the Developers will never turn into Increments. Moreover, by investing all the efforts upfront, you may fall victim to the sunk cost fallacy, delivering less value than possible.)
• Outdated issues: The Product Backlog contains items that haven’t been touched for several weeks or more. (That is typically the length of three 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 detailed and estimated: All Product Backlog items are entirely detailed and estimated. (That is too much upfront work and bears the risk of misallocating the Scrum team’s time. The refinement of Product Backlog items is a continuous effort only to the point where the Scrum team feels comfortable turning these items into Increments.)
• Component-based items: The Product Backlog items are sliced horizontally based on components instead of vertically based on end-to-end functionality. (This may be either caused by your organizational structure, an effect called Conway’s law. In this case, overcome this organizational debt by moving to cross-functional teams to improve the Scrum team’s delivery ability. Otherwise, the Scrum team should invest in a workshop on writing better Product Backlog items.)
• Missing acceptance criteria: There are Product Backlog items that need additional acceptance criteria without listing them. (It is unnecessary to have all acceptance criteria ready at the beginning of the refinement cycle, although they would make the task much more accessible. However, all Product Backlog items need to meet the Definition of Done and—probably—specific requirements at the work item level. If the Definition of Done does not provide the latter ones, the now necessary acceptance criteria shall result from the refinement process.)
• No more than a title: The Product Backlog contains items that comprise little more than a title. (Creating noise by adding numerous “reminders” to the Backlog, thus obfuscating the signal it shall provide, will diminish the Scrum team’s capability to create valuable Increments for the customers. Ideas do not belong in the Product Backlog; they are part of the product discovery system.)
• User story author: The Product Owner invests too much time upfront in creating Product Backlog items, making them too detailed. (If a work item looks complete, the Developers might not see the necessity to get involved in further refinement. This way, a “fat” Product Backlog item reduces the team’s engagement level, 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.)
• No research: The Product Backlog contains few to no spikes or time-boxed research tasks. (This effect often correlates with a Scrum team spending too much time discussing future problems instead of researching them with a spike as part of a continuous Product Backlog refinement process.)
• Involving the Scrum team—why? The Product Owner is not involving the entire Scrum team in the Product Backlog refinement process and instead relies on just the “lead engineer” and a designer. Moreover, the Developers are okay with this approach as it allows them to write more code which they prefer over figuring out what is worth building. (When trying to solve a complex problem, there are no experts but many competing ideas. Therefore, limiting the active participants in refinement activities to a few team members instead of the whole Scrum team increases the risk of falling victim to confirmation bias as the diversity of opinion is artificially limited.)

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 Product Goal and overall product vision. (A serious objective answers the “What are we fighting for?” question. It is also a negotiation between the Product Owner and the Developers to a certain extent. The objective is focused and measurable, as the Sprint Goal and the Developers’ forecast go hand in hand.)
• No business objective, no Sprint Goal, just random stuff: The Product Owner proposes a direction that resembles 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 composing and 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 have not been refined. (Principally, it is the prerogative of the Product Owner to make such kinds of changes to ensure that the Developers work 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 ordering the Product Backlog and improving team communication. Or the Product Owner needs support to deal with pushy stakeholders.)
• Output focus: The Product Owner pushes the Developers to take on more tasks than they could realistically handle. Probably, the Product Owner is referring to former team metrics such as velocity to support their desire. (This is also a road to becoming a feature factory and deserves attention from the team’s Scrum Master. It violates the Developers’ prerogative to pick Product Backlog items for the Sprint Backlog and Scrum Values.)
• No preparation: The Product Owner does not invest adequately in continuously refining an actionable Product Backlog in collaboration with the Developers. (The Product Backlog needs to represent the best possible use of the Developers’ time 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, 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:

• Absent PO: The Product Owner is absent most of the Sprint and is not available to answer questions of the Developers. (As the Sprint Backlog is emergent and the Developers may identify necessary new work or the scope of previously identified work may need to be adjusted, the Product Owner’s absence can leave the Developers in the dark, risking the accomplishment of the Sprint Goal.)
• PO clinging to tasks: The Product Owner cannot let go of Product Backlog items once they become part of the Sprint Backlog. For example, the Product Owner increases the scope of a work item or changes acceptance criteria once the Developers select this Product Backlog item for the Sprint Backlog. (There is a clear line: before a Product Backlog item becomes part of the Sprint Backlog, the Product Owner is responsible. However, once it moves from one backlog to the other, the Developers become responsible. If changes become acute during the Sprint, the team will collaboratively decide 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 provide feedback on work items from the Sprint Backlog once those are done. Instead, they wait until the end of the Sprint. (The Product Owner should immediately inspect Product Backlog items that meet the acceptance criteria. Otherwise, the Product Owner will create an artificial queue within the Sprint, unnecessarily increasing the cycle time. This habit also puts reaching the Sprint Goal at risk. Note: Inspecting Product Backlog items does not equal some sort of work acceptance or quality gate. There is no such thing in Scrum. Once a Product Backlog item meets the Definition of Done, it can be released into the hands of users.)
• Sprint stuffing: The Developers accomplished the Sprint Goal early, and the Product Owner is pushing them hard to accept new work from the Product Backlog to fill the “void.” (The Scrum Team decided collaboratively on the Sprint Goal, and the Developers committed to delivering. Consequently, it is the prerogative of the Developers to decide on the composition of the Sprint Backlog. Should they manage to accomplish the Sprint Goal before the Sprint’s end, it is their sole decision to fill the remaining time. Accepting new work from the Product Backlog may be one way of filling the remaining Sprint time-box. This also applies to refactoring parts of the tech stack, exploring new technology that might be useful, fixing some bugs, or sharing knowledge with fellow teammates. Scrum is not in the business of maximizing the utilization rates of team members. Achieving the Sprint Goal is sufficient.)
• Sprint cancellations without consultation: The Product Owner cancels Sprints without consulting the Scrum 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 rest of the team. Maybe, someone has an idea on how to save the Sprint Goal, provided it is still useful? Misusing the cancellation privilege indicates a serious team collaboration issue and a lack of commitment to live Scrum Values.)
• No Sprint cancellation: The Product Owner does not cancel a Sprint whose Sprint Goal can no longer be achieved or has become obsolete. (If the Scrum Team identified a unifying Sprint Goal, for example, integrating a new payment method, and the management then abandons that functionality mid-sprint, continuing working on the Sprint Goal would be wasteful. In such a case of obsolescence, the Product Owner has to 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:

• Assignments: The Product Owner assigns tasks directly to team members. (The Developers self-organize their work: “No one else tells them how to turn Product Backlog items into Increments of value.” Source: Scrum Guide 2020.)
• Additional work: The Product Owner or even other stakeholders attempt to introduce new work to the current Sprint during the Daily Scrum. (This behavior may be acceptable for high priority bugs, although the Developers should be aware of those before the Daily Scrum. Otherwise, the composition of the Sprint Backlog is the sole responsibility of the Developers: they may accept new work during the Sprint; however, that is their sole decision.)

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 Developers and figure out collectively in what direction to take the product next, some Product Owners do not get the message:

• Selfish PO: Product Owners present “their” accomplishments to the stakeholders. (Scrum is a remarkably egalitarian affair: No one has any authority to tell teammates what, when, or how to do something. There are no sub-roles on Scrum teams, and there is no hierarchy. Instead, Scrum builds everything on self-management and collective responsibility—the Scrum team wins together, and the Scrum team loses together. Remember the old saying: There is no “I” in “team?”)
• “Acceptance” by the PO: The Product Owner uses the Sprint Review to “accept” Product Backlog items that Developers consider “done.” (A formal “acceptance” of work packages by the Product Owner is not foreseen in Scrum, for there is the Definition of Done. However, a feedback loop—did the Developers deliver the agreed-upon functionality?—is valuable. However, Product Owners should also decouple this feedback loop from the Sprint Review. Instead, Product Owners should communicate with the Developers whenever needed or when work items meet the Definition of Done.)
• Unapproachable PO: The Product Owner is not accepting feedback from stakeholders or the Developers. (I get it: Loving your solution over the customers’ problems feels good. Moreover, a bit of confirmation bias may prevent our Product Owners from getting distracted from pursuing their beloved solution. But unfortunately, they do not get paid to roll out their solution. This “living in their PO bubbles” approach hence violates the prime purpose of the Sprint Review event: Figure out collaboratively whether the Scrum team is still on track to meeting the Product Goal—which requires openness on the side of the Product Owners in the first place.)

Food for Thought

Product Owner vs. Product Manager: Do we need a Product Manager in an organization dedicated to practicing Scrum? Often, particularly in larger organizations, we notice a separation between these two roles: The Product Owner is a tactical job at the team level, delivering what the Product Manager created at the organizational level.

Is this a beneficial division of responsibilities, given that our Product Owner must also be responsible for product discovery if the Scrum team is successful?

Conclusion

Admittedly, the Product Owner role is the most challenging Scrum role, and the higher the expectations, the easier it is to fail.

We do not get paid as a Scrum Team to practice Scrum. No stakeholder cares for that aspect as long as we create value ethically, legally, and within existing governance rules. However, we get paid to improve our customers’ lives while contributing to our organization’s sustainability.

In that model, the Product Owner is the linchpin of value creation as they decide where to take the Scrum Team next. No other role in Scrum can contribute to mediocre outcomes like the Product Owner—garbage in, garbage out. You may also agree that any successful Product Owner is a Product Manager at heart.

Thankfully, there is always room for improvement, even in the challenging Product Owner role. This list of Product Owner anti-patterns can serve as a starting point for growth and development.

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

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 42,000-plus subscribers.