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

TL;DR: The Scrum Product Owner Anti-Patterns

If you are working as a product owner, there is — very likely — room for improvement. I curated this list of the most common product owner anti-patterns to help you up your game.

If you like to improve on those you recognize why don’t you ask the scrum master and the team for support? The product owner anti-patterns list is a good starting point for a retrospective.

Product Owner Anti-Patterns — 31 Ways to Improve as a PO by Age of Product

Product Backlog and Refinement 

You can spot most of the product owner anti-patterns in the PO’s backyard — the product backlog and its refinement:

  • Prioritization by proxy: A single stakeholder or a committee of stakeholder prioritizes the product backlog. (The strength of Scrum is building on the strong 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 the priority. Take away that empowerment, and Scrum turns into a pretty robust waterfall 2.0 process.)
  • 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.)
  • 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 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: There are user stories with an extensive list of acceptance criteria. (This is the other extreme: the product owner covers each edge case without negotiating with the team. Typically, three to five acceptance criteria are more than sufficient.)
  • 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 a 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.)
  • INVEST—what? The product owner is not applying the INVEST principle by Bill Wake to user stories. 
  • 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 a 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 limitations.)
  • 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).
  • ‘I know it all’ PO: The product owner does not involve stakeholders or subject matter experts in the refinement process. (A product owner who believes to be either omniscient or a communication gateway is a risk to the Scrum team’s success.)

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 provide a sprint goal, or the chosen sprint goal is flawed. (An original sprint goal answers the “What are we fighting for?” question. It is a negotiation between the product owner and the development team. It is focused and measurable, as sprint goal and team forecast go hand in hand. Lastly, the sprint goal is a useful calibration for the upcoming sprint.)
  • Calling Kanban ‘Scrum’: The sprint backlog resembles a random assortment of tasks, and no sprint goal is defined. (If this is the natural way of finishing your sprint planning I, 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 prioritizing 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 user stories that do not meet the definition of ready. (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 user stories 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 prioritization 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.

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. (That creates a micro-waterfall approach for the duration of the sprint.)
  • PO clinging to tasks: The product owner cannot let go product backlog items once they become sprint backlog items. For example, the product owner increases the scope of a user story. 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 sprint backlog item 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 a core scrum principle.)
  • Delaying PO: The product owner does not accept sprint backlog items once those are finished. Instead, he or she waits until the end of the sprint. (In the spirit of continuous integration, the product owner should immediately check tasks that meet the acceptance criteria. Otherwise, the product owner will create an artificial queue which will 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 lightly 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 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 cancel the sprint.)

Stand-up Anti-Patterns

By comparison to other Scrum ceremonies, the stand-up is remarkably resilient to product owner anti-patterns. There is only one serious:

  • Planning meeting: The product owner hijacks the stand-up to discuss new requirements, to refine user stories, or to have a sort of (sprint) planning meeting.
  • A talkative (PO) chicken: The product owner — at least in my eyes — is more a “chicken” than a team member in a stand-up. Talking too much may hence be an issue. (The product owner who is also a part-time scrum master is a different scenario, though.)

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 scrum team, some POs simply 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”?)
  • Delayed sprint acceptance: The product owner uses the sprint review to accept user stories. (This should be decoupled from the sprint review. The product owner should accept user stories the moment they are meeting the acceptance criteria.)
  • Unapproachable PO: The product owner is not accepting feedback from the stakeholders. (Such a behavior violates the prime purpose of the sprint review ceremony.)

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 exercising 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 me in the comments.

The Product Owner Anti-Patterns — Related Posts

28 Product Backlog and Refinement Anti-Patterns

Download the ’Scrum Anti-Patterns Guide’ for Free

5 thoughts on “Product Owner Anti-Patterns — 31 Ways to Improve as a PO”

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

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

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

    Maria

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

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

    Adil

Leave a reply

Your email address will not be published. Required fields are marked *