Hands-on Agile: Product Owner Anti-Patterns
Hands-on Agile: Product Owner Anti-Patterns
The sixth edition of the Hands-on Agile series takes a close look at Product Owners and some anti-patterns they may be employing.
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
Note: If the browser will not play the videos, click here to watch them.
Webinar Product Owner Anti-Patterns Replay: The Episodes
- The first episode covers the oversized product backlog: 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. The Product Owner is probably 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.)
- The second episode covers creating the product backlog in the wrong way: The Product Owner treats product backlog items not as a token for discussion to build a shared understanding of the why, how, and what with the team, but as deliverables. Often, the PO creates product backlog items upfront by copying from requirement documents without including other members of the Scrum team.
- The Third episode covers the weak Product Owner: The PO has not learned to say no to stakeholders demanding new requests. Trying to being everybody’s darling creates mediocre products that do not scale, though. It also defies the Product Owner’s most important duty: protecting the product backlog from tasks with little or no value.
- The fourth episode covers prioritization by proxy: A single stakeholder or a committee of stakeholder prioritizes the product backlog — not the Product Owner. (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.)
- The fifth episode covers the omniscient Product Owner: The PO does not involve stakeholders or subject matter experts in the refinement process, and probably not even the Scrum team. (A Product Owner who believes to be either omniscient or a communication gateway is a risk to the Scrum team’s success.)
- The sixth episode covers the lack of a sprint goal: 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.)
- The seventh episode covers the pushy PO: 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.
- The eighth episode covers how the Product Owner might be toying with the definition of ready. The PO 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.)
- The ninth episode covers the absent Product Owner. If the PO is not available for immediate clarification, he or she will create artificial queues that probably will put the Scrum team’s sprint goal at risk. For example, 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. (This anti-pattern creates a micro-waterfall approach for the duration of the sprint.)
- The tenth episode covers the Product Owner who 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.)
- The eleventh episode covers the selfish Product Owner, presenting “his or her” accomplishments to the stakeholders. (Remember the old saying: "There is no 'I' in 'team'"? The sprint review is a moment for the developers to shine. The Product Owner should step back.)
- The twelveth episode covers the unapproachable, the broadcasting Product Owner. The PO is not accepting feedback from the customers and the stakeholders. (Such behavior violates the prime purpose of the sprint review ceremony: getting feedback from customers, users, and stakeholders, answering the most critical question of the ceremony: Are we still on the right track, are we even creating value?)
- The last episode summarizes the dirty dozen of the Product Owner anti-patterns: From an oversized product backlog to the lack of a sprint goal, to not letting go of items once the sprint starts. Don’t miss the next Hands-on Agile mini-series on Scrum master anti-patterns and subscribe to this Youtube channel.)
Agile Transition – A Hands-on Guide from the Trenches
The Agile Transition – A Hands-on Guide from the Trenches e-book is a 212-page collection of articles I have been writing since October 2015. They detail the necessary steps to transition an existing product delivery organization of over 40 people strong to Agile practices.
Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.