Product Owner and UX
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
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.
> 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.
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
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
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.
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