Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How a Product Owner Can Drive the Feature Team Crazy

DZone's Guide to

How a Product Owner Can Drive the Feature Team Crazy

Agile teams rely on solid Product Owners to drive the functionality of a team. Here's how a not-so-great Product Owner can cause issues with a team's productivity.

· Agile Zone ·
Free Resource

You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang

Your corporation has decided to implement Agile. At some level, someone sold the organization on the popular software development framework and eventually feature teams were formed. Those teams come with a resource from the business, who is often referred to as a Product Owner. This individual is considered part of your feature team, providing that direct link with the knowledge that is so often needed by developers and testers when implementing new features.

However, there are some things that Product Owners can do that will drive the feature team crazy. In this article, I thought I would share a few of my favorite such items.

Including, But Not Limited To

Having a Product Owner who is afraid to be fully devoted to the team and not put his/her reputation on the line, can be very frustrating. In this example, the Product Owner who is always hesitant to agree to the acceptance criteria for the given feature for fear that something might not come to mind would try to slip in the phrase "including, but not limited to" within the description of the needs of the story.

To this Product Owner, the thought was that the phrase left some more extra room in the event a new requirement surfaced or was recalled after the story had been groomed, scored, and planned for work.

Each and every time, we called the Product Owner out, forcing those scope-creep-enabling words out of the story. Still, this particular Product Owner would continue to find ways to keep the acceptance criteria open for scope-expanding interpretation.

I Know What I Don't Want, But I Don't Know What I Want

Another approach I have encountered is the Product Owner who doesn't really have a solid vision — but is certain what is not in the ideal solution. As a result, the design sessions focused on formulating an understanding of the desired functionality becomes tough when the Product Owner continues to state, "I know what I don't want, I just don't know what I want." Reading those words, brings back challenging memories.

Part of the Product Owner's responsibility is to have a clear understanding and vision for the given feature or epic. If the Product Owner doesn't have a strong grasp on either, it is his/her responsibility to pursue direction from the business. Bringing a vision which is incomplete into the feature team quickly becomes not only a waste of time, but a frustrating effort as well.

Offering Development Suggestions

On the other side of the last frustration are those cases where the Product Owner opts to temporarily relocate to a different role on the team. This can range from offering logic or development design suggestions to even providing alternative agile software development techniques. I recall one Product Owner asking our team why we haven't tried to utilize "programming pairs" or "extreme development" during our sprints. Another Product Owner suggested, "Why don't you just create a new class for all that logic?"

When I have encountered these type of suggestions, the product owner typically has maintained some development experience during their career. While in most cases the intent is to be helpful, more often than not their ideas are typically not in line with the discussions taking place.

Non-Existent

By far, the most common way in which a Product Owner can drive a feature team crazy is by simply not being engaged. When the Product Owner is non-existent, the feature team's productivity suffers greatly as they wait for the opportunity to ask clarifying questions, receive feedback from outstanding items, validate features which have passed QA testing, or to receive new stories and directions. These are just a few examples of how a non-existent Product Owner has hampered the productivity of teams I have participated in over the last five years.

Agile teams have Product Owners for a reason and their value is equally as important as every other member of the feature team. This is no different than a feature team where the developers or quality assurance staff are non-existent.

Conclusion

I am a proponent of the Agile software development framework and appreciate the ability to have a dedicated resource from the business. In my experience, I have worked with some amazing Product Owners; one example was noted in my "The Secret to a Superior Product Owner" article (February 2017). I have also had the misfortune to work with some really disconnected product owners as well — most of which have helped populate this article.

In the spirit of trying to find the good in all things, having experienced not-so-great Product Owners totally made me appreciate when an amazing Product Owner is part of my feature team.

In what ways has your Product Owner introduced challenges into your feature team? I would enjoy hearing your feedback in the comments section.

Have a really great day!

Download the free agile tools checklist from 321 Gang. This guide will help you choose the right agile tools to position your team for success. 

Topics:
agile adoption ,product owner ,challenges ,acceptance criteria ,requirements ,Agile ,Function Team

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}