Gap between stakeholders and development team during Sprint Review

Since some reviews are based on the backend, it's very difficult to receive feedback from stakeholders.

Are your user stories focused on features that benefit the user? Or are they split between back-end and front-end?

Each user story should have a benefit to someone.

I would like to improve this by having sessions with the stakeholders to find out, which future steps provide most value to our company.

As I understand it, this is one of the main responsibilities of a Product Owner. You should be asking the stakeholders what's important to them in the product. Perhaps taking all of their feedback, ordering the Product Backlog, and sharing it with the stakeholders would be useful? That way they can all see it, understand the order, and question you if they feel differently.

This is always a fun situation. I'm always interested in if the stakeholders are actually interested in the product if they keep themselves at a distance, too. The Scrum framework has just 3 roles in the core, but that does not mean there are no other involvements. And I don't say this to point a finger towards you, but just to point out that everyone needs to be aware of how the dynamics between people evolve the product itself. 

You as a Product Owner are mandated to decide on the priority, based on the information that you have. Creating a team(I don't mean a team like a Scrum Team here) around you with all the needed  domains (think of: marketing, sales, HR, technical knowledge, management etc) creates a valuable network on where to get that information from. I would also work with the Scrum Master here to help the organization understand Scrum and how to actually move forward.

1. That's also one of the main issues. I try to let the stakeholders think of user stories, which we can work out. All we get is features, as the stakeholders do all the thinking for us.

Your feedback helps. We should focus more on user stories. This way it makes sense if during one review we discuss the backend of our systems.

2. I'm trying to achieve agreement among stakeholders during the Reviews by asking them how important the next steps are. However, they are not able to express this in value. Last Review we started to show the backlog. All stakeholders discussed about how important certain features were to them (because of previously made promises to customers), but in the end of the Review there was no agreement between them. Eventually, I had to choose the order to finish the discussion. The developers were present during this discussion. I'm not sure if it benefits the development team to be present during these discussions.

The stakeholders aren't asked yet to give values to certain features/epics, which makes it for me, as a product owner, hard to prioritise the backlog.

How does stakeholder excitement (and the delivery of true value) relate to involving them (before the review)?

Since some reviews are based on the backend, it's very difficult to receive feedback from stakeholders. 

What "value" can a stakeholder or end user evaluate through the "back-end" delivery of functionality?

Your situation seems to be a symptom of incorrect item splitting by architecture/specialization, which takes Development Team members into account, but unfortunately disregards the stakeholder and end-user perspective.

I often encourage my teams to ensure that every item they work on is somehow customer-facing.   See if you can try this as an experiment, and if it improves stakeholder interest.   

Also, pay close attention to any constraints or issues revealed through such an approach.

This is from the Scrum Guide section describing the Product Owner role(emphasis added by me):

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;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

Creating items in the Product Backlog that will result in some form of user facing functionality will help optimize the work as it provides a mechanism for involving the stakeholders.  For example, assume you are building an application that provides the user the ability to create and manage a list of items from a database.  Rather than building the entire backend to allow for create, read, update, delete then put a front end on top you could build a small portion that allows the user to read only.  Put fake data in the db, and then show the users the presentation layer.  Ask them how they would like to interact: edit in line, pop up to show entire record, how to delete a line.   That will feed into the next round of how you build.  Show them a piece (i.e. increment) of the application at the end of each sprint. It could be a new part of functionality or updated functionality from last review based upon their feedback.  This will draw the stakeholders into the process and allow the developers to feel like they are actually providing value. 

The developers might want to revert to the backend then frontend method but once you can show them how doing a full vertical slice of feature provides value over the horizontal slicing they will start to appreciate it. Work with your Scrum Master on the messaging and getting the team to experiment with the experience.

Stakeholders don't get excited of the increments. Since some reviews are based on the backend, it's very difficult to receive feedback from stakeholders.

Is each increment in an immediately releasable condition? To what extent do stakeholders use each increment, for real, and thereby empirically assess the product Sprint by Sprint?

Thank you all for your input. I believe I have spotted two major issues:

Each user story should have a benefit to someone.

The backlog should contain more user stories which emphasize the intrinisic problem of a customer. Currently, the internal stakeholders request features, which solve one part of a problem. They should be guided more in explaining the WHY, so the scrum team can work out the solutions to the problems.

I often encourage my teams to ensure that every item they work on is somehow customer-facing. See if you can try this as an experiment, and if it improves stakeholder interest.   

The team should think of creating customer-faced increments (with help of clear user stories). This should benefit the feedback we receive during reviews and then the presence of the development team during stakeholder discussions will make more sense.

I will use your feedback for improving these two problems.