User stories with multiple approaches

Your problem arises from the fact that you reason from the solution. My question to you would be: What do you need to implement to optimize value for your shop?

• Is it most important to reduce check-out time, so you increase customer satisfaction and reduce the number of cashiers needed?
• Is it most important to reduce the inventory as you have too much decaying fresh food?

Then write one user story to reflect the added value. Implement it, measure the effect and only then think about whether you want to improve the solution. 

Let's say that, in version 1, we would like to implement the 1st approach. And in version 2 the 2nd approach.

How should I reflect this in my User Story ?

Perhaps it would be best not to try. If you did, the independence of the stories might be reduced and the INVEST criteria thereby compromised. Try forecasting releases through Product Backlog grouping and ordering instead.

Remember that each story ought to be just sufficient to allow a valuable lesson to be learned, such as “what are the check-out queue times when manually weighing?” Actionable data like this can then shape the next release.

Thanks for your comments. I'm really new in the User Storytelling think. And I find it hard to get the right balance between the big picture and the Sprint timebox. To move from the Business Requirement to a set of User stories required to implement the Business Requirement.

If I reword my User Story into:

As a Manager

I would like to

- retrieve the weight of the buyer's purchased product

In order to:

- maintain the product's stock in the system to the real quantity available on the shop, in order to be able to detect when the product must be re-orderd from the supplier.

During the backlog refinment, with the product owner, we decide that the best approach that will fit general planning will be

" Let the employee weight manually the product and introduce the weight manually on the cash register".

We implement this way.

If after the tests or the go-live, we come to the conclusion that the process-time is too long, we introduce a new User Story such as

As a Cashier

I would like to

- retrieve the weight of the buyer's purchased product directly on my cash register

In order to:

- speed up the chekout process

Is that a good approach ?

My practice is that technical details are part of a story only when absolutely necessary.  Your original story states the problem, the reason, the value and how to know it is accomplished. As a PO you have provided what you should.  As a Development Team it is up to you decide the best technological approach to solve the problem.  As a Scrum Master it is up to you to help the people in those roles respect that the others are doing the right thing.

But what if the first solution is wrong?  How would you know if you don't get empirical evidence to support that decision? Put it out, let the stakeholders come back to you with their findings.  Inspect the new information and adapt.  Remember that anything can be changed.  And it could be that the simplest solution is enough. But unless you deliver it, you will never know.  To play devils advocate, your second and third options might be introducing cost to the stakeholders and it is possible that some of the stakeholders can not afford to cover those costs.  You may find that you need to provide more than one solution based on the demographic makeup of your stakeholders. 

Iterate on your solution until you find the one that satisfies the stakeholders needs. 

Looking at your rewording, the user story still contains solutions. I highlight them in bold:

As a Manager, I would like to 

retrieve the weight of the buyer's purchased product

In order to:

maintain the product's stock in the system to the real quantity available on the shop, in order to be able to detect when the product must be re-orderd from the supplier.

Also the story does not say way the re-ordering moment is a problem for you. 

Instead, you could think of what you want to achieve. You could reword it like this (assuming the shop was often late in re-ordering):

As a Manager, I would like to

re-order products at the most optimal time,

so that my customers are not dissatisfied with empty shelves. 

The development team now knows what the goal is, namely customer dissatisfaction caused by empty shelves (maybe you did a survey on customer satisfaction). I can imagine different solutions, but a simple one would be:

A piece of paper in the warehouse where the number of boxes is written down when a product arrives. Every employee writes down how many boxes are put on the shelves in the shop. Manually checking this paper administration may improve re-ordering

Although this solution is somewhat expensive in employee processing time, if the shop is small it might be totally feasible and costs nothing to implement. Then a new survey can prove that customer satisfaction has indeed increased. Assuming you are indeed successful, you have increased the perception of your shop in the neighborhood, which is probably a very good thing. Now you can think about optimizing the solution. 

The point is, by just specifying what kind of value you want to achieve (in this case higher customer satisfaction) you leave the team free to come up with a great solution that might be totally different than what you thought of. 

The below link has been a guide for me,

https://www.ebgconsulting.com/Pubs/Articles/SlicingRequirementsForAgile…

The trouble I've got with this one:

As a Manager, I would like to

re-order products at the most optimal time,

so that my customers are not dissatisfied with empty shelves. 

is that it fits what I hear in the term "User Story" (the perspective of the user), but not the Agile "User story", that should also fit the Sprint timeframe.

So let's say that the team decides of a first iteration, that Product Owner recognizes has bringing some added value for him. But this solution spans over multiple sprints. What do we do ?

Introduce tasks in the user stories and plan the tasks in the sprint ?

Make of this (User-perspective) User story an Epic user story and introduce Agile-User stories that will fit into a sprint ?

is that it fits what I hear in the term "User Story" (the perspective of the user), but not the Agile "User story", that should also fit the Sprint timeframe.

If you look back at the solution I wrote with a 'developer hat' on, you will see that it involves putting up a piece of paper and prepare a survey to monitor whether better supplied shelves actually make the customers more satisfied. That 'development work' should fit any sprint time frame. 

But at this point we don't know enough about the context of the original question to go much further.