Creating US that are independent

I wouldn't agree that you need to add something to the cart to visualize what is in the cart. Assuming you're building software for an online store or marketplace, you could build an end-to-end slice of work that displays a shopping cart view based on pre-seeded data. They are independent since you can complete each piece of work, as its defined, without completing the other. However, I would argue that slicing the work into "add something to cart" and "visualize the products" violate the Valuable criteria. A user will not get value out of visualizing products or adding something to their cart. A marketplace owner will get value about listing items for sale while a customer gets value out of browsing and searching items and completing a purchase.

Let's take an easy example : a shopping cart. One US would be to add something in the cart, the other to visualize the products to put in the cart. They are not independent cause I need to visualize what to put in the cart to add something in it.

Perhaps they have dependencies in that sense. However, that isn't what we mean by independent here. Consider the following PBIs for a shopping cart:

• Add item
• Remove item
• Work out total to pay
• Work out sales tax
• Purchase contents

These PBIs could well be independent. You might have to do them in a certain order -- I'd suggest the order listed -- but get the order right, and each could be brought into progress and completed one at a time.

The most valuable of these items might be the ability to add and remove items: to have a shopping cart worthy of the name, it must be possible to do those two things. You should be able to work out the total and the sales tax as well, and if you could purchase the contents financial value would accrue, even though the act of purchasing might not be a feature of the cart at all. Hence three out of those five PBIs represent potential scope contingency, each of which could be sacrificed if need be while still meeting the Sprint Goal of building a minimally viable shopping cart.

Thank you for your answers! I think I'll create a second post because my question is actually broader.

To me, it seems your dilemma revolves around releasing each story when it is done.  There is nothing that says that each story has to be released.  The increments are expected to be usable but that does not mean that they have to be releasable. All of the examples that have been given show individual stories that are independent, negotiable, valuable, estimable, small and testable.  The dilemma is that releasing each one to a stakeholder might not give the full value that they want.  However, the value of doing them in this manner will be felt primarily by the Scrum Team.  

Take the example of 

 One US would be to add something in the cart, the other to visualize the products to put in the cart.

Each of these stories can be done independent and tested using mock data. They each could be shown to the stakeholders using mock data.

You can show the visualize the cart before the addition of items to the cart using mocked up data. The will allow the stakeholders to provide feedback. They may not like the way the cart is presented.  They may want to have more or less product detail shown.  They may want it sorted in the order in which it was added or by category (produce, dairy, canned goods for example if it was for a grocery cart). 

You can create the ability to add items to the cart and show that to the stakeholders for feedback.  There could issues with the way you are required to select the item. Maybe the notification that the item has been added is not prominent enough or too invasive for their liking. 

Getting that feedback sooner than later will allow the Scrum Team to adapt quicker.