Skip to main content

Product Owner and UX

Last post 04:35 pm February 22, 2014 by Joseph Assaf
6 replies
01:06 pm February 21, 2014

Hello Everyone,

How much a product owner should be involved in the UX design as this is a critical part of any software usability.
If the product owner provides the stories, how can he/she be sure that the design will be appropriate? How to integrate the UX design in the Scrum in this situation?

For example:

Product Owner story: As a user I want a click button to delete a page.
User story can fit in the sprint if it is a straight thing. BUT if the dev team raises the fact during the sprint that the click button should be on the specific location, with a specific attribute because it would be easier and more UX appropriate, that means the Story is not valid as is anymore or the estimation was wrong.

Should the Product owner include a UX expert during the story creation with the users?

Regards


02:38 pm February 21, 2014

Product Owners should work closely with the UX designers during the creation of user stories and acceptance criteria (backlog grooming). Once the Product Owner and the UX designers have agreed on *what* should be developed those user stories would be candidates for an upcoming sprint where the UX designers and other development team members can implement them. The Development team can demonstrate their work to the P.O. and the P.O. can decide if future modification are needed or not. If modifications are need the P.O. would create new user stories and acceptance criteria (with the help of UX designers, if needed) to enhance the current functionally, prioritize them in the PBL and process continues again.


04:15 am February 22, 2014

> How much a product owner should be
> involved in the UX design as this is a critical
> part of any software usability.

If usability helps determine the priorities for each sprint, then the PO must be directly involved. This is because he or she is responsible for the ROI of each increment, and must be able to explain the priorities and essential scope to the Development Team.

> If the product owner provides the stories, how
> can he/she be sure that the design will be appropriate?

The PO will have to work with the Development Team, when reviewing and refining the Product Backlog.

The developers have a duty to make sure that they can deliver the work on their Sprint Backlog. If they don't have UX skills they may demand further clarification, such as wireframes, before they accept UI work into a Sprint.

> How to integrate the UX design in the Scrum in this situation? 

If UX is essential to making a release then the Development Team must have the relevant skills to meet that part of the Definition of Done. The PO must be able to review the UX work and provide guidance as needed.

> Should the Product owner include a UX expert during the story creation with the users? 

Perhaps...as long as the expert helps the PO to clarify the business value in UX decisions, and does not prescribe an implementation.

The developers are responsible for implementating the requirements in liaison with the PO. This includes the development of any creative aspects that may add value to the business brief they are given.


04:50 am February 22, 2014

Thank you both!
Very valuable.

As you know, UX is a tricky field, I am not expecting the UX expert to define what stories should go in the backlog, but some designs should probably be implemented before others if we want a possible release to happen (unless the release is modified with the PO)

But also, during development (and taking in consideration that the development team is fully qualified to develop the product), some issues in the provided design might cause problems and might require new stories to be created (for example if an incomplete storyboarding shows only while developing it). This would eventually impact the release plan and probably increase the number of estimated sprint for a final shippable product.

How would you deal with such situation?

Regards


05:13 am February 22, 2014

Changes in a Product Backlog due to requirements discovery is only to be expected, and is one of the reasons for delivering work in sprints. Any plan for making releases must be flexible enough to take these amendments into account. The ability to support release on demand is encouraged.

Changes in scope do not necessarily mean an increase in the number of sprint


05:18 am February 22, 2014

Changes in a Product Backlog due to requirements discovery is only to be expected, and is one of the reasons for delivering work in sprints. Any plan for making releases must be flexible enough to take these amendments into account. The ability to support release on demand is encouraged.

Changes in scope do not necessarily mean an increase in the number of sprints. The work that a Development Team is requested to do over a given number of sprints is a matter of backlog prioritization by the Product Owner.


04:35 pm February 22, 2014

Thank you, I will than have to rework on the backlog to incorporate those discoveries.
It is unreasonable of me to think that design can be completely covered before dev, even with UX experts


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.