Product Owner/Maximizing Value

The PO maximizes value. This does not mean the PO always picks the most valuable items first: perhaps he can get two slightly less valuable but also less complex items instead.

It really depends on the motivation: does the PO want to add in that simple item just for the sake of doing similar things together, or does the simple item actually have good value for the work it entails?

 

The PO won't look simply at the value of the items themselves, but will use them to negotiate a valuable Sprint Goal with the Development Team. The items planned into the Sprint Backlog will be a forecast of the corresponding work.

Is the value something you add to a user story ?

When your client is stuck with the idea that everything is important and wanting all at once, how do you guess prioritize your backlog ?

The Development Team should never prioritize the backlog.   The PO owns the product backlog, and the Development Team owns the Sprint Backlog, which is composed of items offered by and negotiated with the Product Owner for the upcoming sprint, along with any other items the Development Team feels are needed in order to meet the Sprint Goal.

From the Scrum Guide:

"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...   The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says."

"Product owner maximize the value of the product done by the development" is this limited to only prioritize the Product backlog items only ? or there is any other things that a PO do for the product during the product development.

"should a PO always produce most valuable items first"

I believe not. In the early ages of Agile the PO was suggested to use ROI for ordering the product backlog. Which is usually either practically impossible or counterproductive. This idea is fortunately not included in the Scrum Guide. On the other hand, if you consider that BABoK deals with basically the same question on hundreds of pages, it is difficult to give a brief answer on how should the PO maximize value. Giving elaborate instructions would hardly fit the length and purpose of the Scrum Guide. I only dare to list some examples of aspects one might want to consider:

1. Understand your planning 'horizon' - do you have a product vision and a roadmap to get there? Your team(s) should understand where are you heading to. What is your MVP? Obviously you cannot have everything at once, so priorities will not only reflect value and importance, but also meaningful milestones, packages on your roadmap.

2. Is your journey truly agile? Can you change direction and priorities when choosing stories for the next sprint, or are you a captive of unfinished, ongoing works and dependencies? The 'Definition of done' and 'potentially releasable increment' may serve well in achieving agility. Working on multiple high priority issues but not having anything delivered at the end of the sprint is hazardous. We can have modern delivery practices and transparent backlogs, indulging ourselves of using Scrum while businesswise not being agile at all.

3. Cross-functional teams many times have people with complementary skills. Your data scientist and your designer are not interchangeable. So planning a sprint which makes some of the team members bored will likely not deliver optimal value.

I would like to emphasize that these are only examples and not even applicable at all times. There is a good reason to leave 'maximizing the value' for the discretion of the product owner.

In reading your question I see "value" and "priority" used which makes me wonder if you are equating the two things.  They are truly two different things and shouldn't be used interchangably.  For example,

Feature A is the most requested feature from the customer base and is needed in order to accomodate some legal changes that go into effect at the beginning of the next calendar year.  Research has shown that if that feature is not introduced you will lose 15% of your customer base and it's absence will impact the ability to gain new customers which wil cost the organizations an estimated $500,000 (USD) in revenue.  Most people would say that it is a very high priority item. However, in order to introduce that feature, the entire application needs to take advantage of functionality that was introduced in a recent change to the technology used in the applications infrastructure.  So it can not be delivered until the infrastructure is updated.   All of this work has been given a high level estimate of taking 6 months and will require everyone in the R&D department, not just a single Scrum Team. 

Feature B is a change to the user interface to update some of the old styling to be more current and easier to understand.  No customer has asked for it specifically but there have been 1000s of customer support calls generated from it because the users are not clear on how to interact with the application.  There is no risk to losing current customers or impact to the ability of gaining new customers.  The cost of the support calls has been minimized by adding some online video tutorials linked from an FAQ section. The effort to do this as been given a high level estimate of 4 weeks and requires only 3 members of the Scrum Team.

Which of these would be the most valuable to deliver first? The simple quick win of the user interface upgrade or shutting down all work on the application for 6 months which means not even being able to deliver bug fixes? 

The Product Owner is responsible for identifying the best items to delvier the approrpriate value at the right time. Not to deliver the highest priority item.