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.
