Product Owner Anti-Patterns — 33 Ways to Improve as a PO

TL; DR: Scrum Master Anti-Patterns

No other role in Scrum can contribute to mediocre outcomes like the Product Owner—garbage in, garbage out. Therefore, the following list of some of the most common Product Owner anti-patterns might be a starting point to reflect on the role; maybe, there is room for improvement?

If you recognize some anti-patterns in your daily work, why don’t you ask the rest of the Scrum Team for support? For example, run a Retrospective with teammates and stakeholders on how the team is doing regarding figuring out what is worth building.

🇩🇪 Zur deutschsprachigen Version des Artikels: Product Owner Fehlverhalten — 33 Möglichkeiten, sich als PO zu verbessern.

🗳 Update: Join the poll and its lively discussion on LinkedIn.

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

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

📅 Join 230-plus peers on May 30, 2022: HoA #42: The Skinny on Lean Roadmapping and OKRs w/ Janna Bastow.

The Role of the Product Owner According to the Scrum Guide

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The primary way to achieve this goal as a PO is to manage the Product Backlog effectively. According to the Scrum Guide, this activity comprises:

  • Developing and explicitly communicating the Product Goal;
  • Creating and clearly communicating Product Backlog items;
  • Ordering Product Backlog items; and,
  • Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

Source: Scrum Guide 2020.

In my experience, most Product Owner anti-patterns result from a misunderstanding of this Product Backlog management task. Notably, less successful Product Owners tend to fail at the communication part with teammates and stakeholders. Maximizing the value of the Scrum team's work from a customer perspective while contributing to the bottom-line of the organization is less a question of project management skills, juggling with product requirement documents, and keeping the Jira up-to-date.

Therefore, successful Product Owners spend less time on actually 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.

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

Cannot see the form?
Please click here

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.)


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

We do not get paid as a Scrum team to practice Scrum. No stakeholder cares for that aspect. However, we do get paid to improve the lives of our customers while contributing to the sustainable business of our organization. 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.

Fortunately, there is hope as continuous improvement also applies to the Product Owner role. This list of Product Owner anti-patterns 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.

📖 Related Posts

Scrum: 20 Sprint Planning Anti-Patterns

27 Sprint Anti-Patterns Holding Back Scrum Teams

Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team

27 Product Backlog and Refinement Anti-Patterns

Download the Scrum Anti-Patterns Guide for free.

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

Date Class and Language City Price
🖥 💯 🇩🇪 April 10-11, 2024 GUARANTEED: Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 💯 🇬🇧 April 23-24, 2024 GUARANTEED: Professional Scrum Master (Advanced) Training (PSM II; English; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 🇬🇧 May 7, 2024 Professional Scrum Facilitation Skills Training (PSFS; English; Live Virtual Class) Live Virtual Class €749 incl. 19% VAT
🖥 💯 🇬🇧 May 7, 2024 GUARANTEED: Hands-on Agile #61: Toyota Kata Coaching for Agile Teams & Transformations with Fortune Buchholtz (English) Live Virtual Meetup FREE
🖥 💯 🇩🇪 May 14-15, 2024 GUARANTEED: Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class) Live Virtual Class €1.299 incl. 19% VAT
🖥 🇬🇧 May 28-29, 2024 Professional Scrum Master (Advanced) Training (PSM II; English; Live Virtual Class) Live Virtual Class €1.189 incl. 19% VAT
🖥 💯 🇬🇧 June 6, 2024 GUARANTEED: Hands-on Agile #62: From Backlog Manager to Product Manager: From Outputs to Outcomes w/ David Pereira (English) Live Virtual Meetup FREE
🖥 🇩🇪 June 25-26, 2024 Professional Scrum Product Owner Training (PSPO I; German; Live Virtual Class) Live Virtual Class €1.299 incl. 19% VAT

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.

📺 Watch the Video on Product Owner Anti-Patterns

The videos of the webinar are available now:

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

✋ Do Not Miss Out and Learn more about Product Owner Anti-Patterns — Join the 11,000-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Community and 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.

Categories: Agile and Scrum
Stefan Wolpers: Stefan, based in Berlin, Germany, has worked for 18-plus years as a Product Manager, Product Owner, agile coach, and Scrum Master. He is a Professional Scrum Trainer (PST) with Scrum.org and the author of Pearson’s “Scrum Anti-Patterns Guide.” He has developed B2C as well as B2B software, for startups as well as corporations, including a former Google subsidiary. Stefan curates the ‘Food for Agile Thought’ newsletter and organizes the Agile Camp Berlin, a Barcamp for coaches and other agile practitioners.

View Comments (6)

  • Hi, Stefan,
    Great list. IF you don't mind, I'd like to add few things from my experience.
    - some of the points can be hard to achieve if you as A PO has to play few different roles (SME, Commissioning manager, Business/System Analyst, Scrum Master). I'm not saying that you cannot be one of them, but the ideal situation is if you, as PO, can focus entirely on Backlog and Product RoadMap.Simply saying your daytime is only 24hrs not 48hrs :)
    - Grown up development team, developers who are committed, who are able to take responsibility for the sprint
    - if you have a frontend devs and backend devs it is really hard to carry on refinement with entire team. Sometime you have stories which are not touching backend side at all. This is a real challenge for development team to work on stories, which describes business need all together, to not to waste time for waiting on one another

  • Hi Stefan, Thanks for this list and all the anti-patterns you are enumerating to help judge where a team and organization are. I have some questions about the size and information in the product backlog. You say that no more than 3-4 sprints worth of stories is the maximum in the product backlog. Do you mean refined stories that have been sized of split to typical size or any story even high-level ones? I believe that it s acceptable to have more than that as long as the going beyond say 2-3 sprints out are stories only a high level that have the story goal and maybe one or more ACs. For example, we doing 7 sprints of work in our release. We try to have somewhere between two or a little more sprints worth based on typical throughput refined at all times. The stories were created either by a story writing workshop or story mapping review to create a minimum viable solution for our desired business outcome. This gives us a road map and tracking to see if our guess of what will fit is in the general area. We adjust as we go to deliver on time. What issues do you see with this approach? It seems to be working pretty well.

    • To my experience, a product backlog will comprise of stories of all statuses — from high-level and brand-new to small and well refined — at any given time. If delivery is based on releases in your industry and a typical release cycle is about seven sprints then your approach probably is the right one for your organization. (Although I am not a fan of managing the release planning via the product backlog. I would rather see that with the product roadmap.)

  • Hi Adil,

    I agree that a PO may not always be able to order the backlog without help from a SME. However, my take at this point is that the responsibility should fall in one person - the PO. They may do it together with the System Architect but the final approval should come from the PO. The PO needs to understand the thinking behind the ordering so that they are able to respond any questions coming from stakeholders.


  • I'd add this generic anti pattern:

    PO wouldn't change anything, because it's the way it is and it's better to be pragmatic.

  • This is the most comprehensive list of anti patterns I've seen, so thank you.
    I must disagree about a few things. Mainly Prioritization by Proxy and Over Sized.
    For the first one, sometimes, the PO needs help from someone else who knows better. Example, if we are at a point in which we are building elements of the system architecture, and the System Architect may be the person taking on the role of prioritizing what elements should be build when.
    The second: the PBL should have every story that relates to every known release. Unless, we are talking about thousands and thousands of stories. Even then, the team should be using a tool to manage the backlog, and tagging releases (1, 1.1, 1.2 etc.) would make it easy for the team to focus. Wiithout having every story - at least of the first release, the product vision will be blurry.


Related Post