Bsrgvty

I hope someone can help me understand one part of the role of the Product Owner (PO).

In my company, we have a PO that is responsible for the Product Backlogs of all our products. I work as a UX designer. The PO specifies features and requirements to the Teams.

Very often, the PO suggests, in detail, how a user interface of our software should be, such as what type of information is to be displayed in the user interface (e.g. "I'd like to see a date in list" or "I'd like to see so and so in this view"). Often the PO has asked the customer, or knows already, but the product UI ends up being quite cluttered and complex.

I am now introducing user testing to encourage user-centered design and advocate making better design decisions based on user involvement.

My question is: to what extent should the PO describe the requirements of a UI? Should we (the developers and designers) look to the PO to decide and say what the information in the UI should be?

Product Owner is Accountable for the Product, and Responsible for the Product Backlog

My question is: to what extent should the PO describe the requirements of a UI? Should we (the developers and designers) look to the PO to decide and say what the information in the UI should be?

The Product Owner is 100% responsible for defining the features and requirements for the product. The Scrum Guide defines the Product Owner role as follows:

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

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;


• Ordering the items in the Product Backlog to best achieve goals and missions;


• Optimizing the value of the work the Development Team performs;


• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,


• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

In other words, the Product Owner owns the Product Backlog, and is generally the person the organization holds responsible for defining the product's features. So to the extent that a user interface is a feature, as opposed to an implementation detail, the Product Owner is the accountable party.

Increase Your Collaboration

The unspoken implication of your question is that you feel like the Product Owner is defining anti-features, or perhaps micromanaging implementation details that should belong to the Development Team. In either case, the solution is to collaborate more closely, and to increase the level of communications within the Scrum Team as a whole.

• 
  

  Anti-Features

  
  
  

  An anti-feature is something that you strongly believe, in your professional capacity, actively harms the product. If you feel that a Product Backlog Item actively harms the usability or maintainability of the product, then you have a professional responsibility to discuss the issue as a team to address it.

  
  
  

  At the end of the day, the Product Owner has the final say on the product's functional and non-functional requirements. However, the Development Team is charged with implementing the Sprint Goal and delivering the Product Backlog Items in the most effective way possible. These objectives should not be in direct conflict; while there is overlap and differentiation in the roles, both roles are part of the Scrum Team and should be actively collaborating to develop the product.

  
  
  

  If there is conflict or a lack of collaboration, work with your team mates and with the Scrum Master to identify roles, friction points, and process improvements. Continuous process improvement is an essential part of Scrum, and should be a part of each Sprint's inspect-and-adapt cycle.

  
  


• 
  

  Micromanagement

  
  
  

  As a general rule, the Product Owner describes what a feature should do, while the Development Team determines how the feature should be implemented. However, some aspects of product development (user interface being a good example) can fall into both what and how buckets simultaneously. Resolving the dynamic tension of this requires active collaboration and ongoing communication.

  
  
  

  While it is not the Product Owner's place to tell the team how to implement a feature, it is also not the Development Team's place to override the Product Owner's vision for the product. When there is overlap or conflict, mature Scrum Teams collaborate closely so that the source of requirements and the goals of those requirements are clear, and any technical or implementation trade-offs are identified and considered as part of the product development life cycle.

  
  

In other words, anti-features and micromanagement are both things the Scrum Team should avoid, but the way they are avoided is through collaboration rather than rigid, siloed responsibilities. Let's look at an example.

A Worked Example

As a concrete example, consider a story like:

As a web site visitor,

I want all my account-related actions accessible from the navigation bar

so that I never have to go to a separate screen to embiggen a widget.

A successful Product Owner would work with the team to explain the requirements and the objectives, and to provide sufficient context for the team to develop an optimal solution. Meanwhile, the team would provide a solution based on their knowledge and experience that would best meet the goals and constraints provided.

Doing it this way ensures that the solution space is not overly constrained. For example, one way of meeting the goal might be to AJAX in dynamic drop-down menu items. Pre-defining how is usually an anti-pattern, but there are edge cases where look-and-feel are part of a product's requirements.

Perhaps there are other solutions the Product Owner or customer hasn't considered, in which case the team should explore those options and present them for the whole Scrum Team to consider. Then again, perhaps there are reasons that the team's solution won't meet the customers' expectations, in which case the Product Owner acts as the voice of the customer to ask the team to seek an alternative. This level of active collaboration is essential to getting the most value out of the agile development process.

In almost all cases, better user stories that provide more context will help the team hold the necessary conversations around how to most effectively meet the goals for a feature. In addition, test-first development can help the team differentiate between must-do requirements and implementation details by focusing attention on how successful feature implementation will be measured and assessed. The entire Scrum Team should be involved in writing and refining the stories and tests so that collaboration on the increment is baked in from the very beginning of each Sprint.

My question is, to what extent should the PO describe the requirements of a UI?

To the extent that the designers know what to design and the programmers know what to program. In your example, "as a user I want to see a list of dates so I can..." seems to be a good user story. Who else would know what the purpose of that user interface is and what data the users need at that point.

Should we (the developers and designers) look to the PO to decide and say what the information in the UI should be?

Yes. Now the Product Owner might not be a technical person. That means you have to provide feedback on how hard it is to do what the PO requests so the PO can adjust the story accordingly. And you might want to bring in the experience of your job and maybe say "but studies have shown comparing dates is easier done in a grid than a list" or "but the design guidelines of the mobile device say it should never be blinking. Maybe we can use bold font instead?".

But in the end, the decision what data to display is a clear cut Product Owner responsibility. How it is displayed is the job of the dev team. Ideally, the whole Scrum team talks about this in the Backlog Refinement Meeting.

As you are talking about a Product Owner I am going to assume you are using Scrum.

As you mention in your question, it is the responsibility of the Product Owner to prioritise and maintain the backlog of requirements. They also ensure that the team fully understands these requirements.

It is the development team's responsibility to decide how to implement the backlog items.

To quote from the Scrum Guide:

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality

So far we have been discussing responsibilities. How the team works together is just as important.

I would hope that the development team welcomes any input or suggestions that the Product Owner makes on implementation. Equally the development team may make suggestions to the Product Owner about requirements and priorities. If you are doing user testing this becomes even more significant.

However, the responsibilities are clear. The Product Owner has the final say on the product backlog and the development team has the final say on implementation.

For your title, the clear cut answer is yes. The product is for a purpose, and they are the ones defining that purpose. In fact it’s quite common to have place holders that say things like “get legal verbiage and place here”. Just as you don’t make up your own legal or product support language, you don’t get to override the product owner on other similar matters, such as whether a displayed date will be a date only or a date and time.

For the question as asked in your body, it’s a bit more complex.

Your UI expertise should come in how best to display what they want displayed. Should dates be dd/MM/yy, yyyy-MM-dd, Saturday, June 12, 1956 at 4:15 in the morning, or something else? So, you should be free to push for particular looks and to push back against others. List vs grids vs dropdowns, those are the kind of things that you should generally be deciding. But depending on the product, they may override you even on that — internal apps where they are the key user, “I find this confusing” is a valid statement no matter how much your research says that it should be clearer.