Multiple stories related to the same code or user interface
It is pretty easy to just split user stories to fit them into a single sprint but the problem is the developers, who are claiming that they can't build some stories parallel because they are modifying the same part of the user interface or piece of code in the back end. From the PO's viewpoint, those stories are important to get implemented during the sprint but that's not happening if the developers couldn't do the work. I think it is obvious that contributing to the common sprint goal will affect to same code.
Do you have any ideas to solve that kind of problem?
From the PO's viewpoint, those stories are important to get implemented during the sprint
Why? What happened during Sprint Planning? Aren't those selected Product Backlog items just a forecast of the work required for the Sprint Goal to be met?
If I have understood right, Scrum Team's primary focus is to achieve the Sprint Goal during the sprint, and because of that, the team chooses those PBIs, which they think to help to achieve it. So if the team won't implement enough work during the sprint, we won't have any potentially releasable product increment or the Sprint Goal won't be achieved, right? So what can I do if I have enough PBIs to achieve the Sprint Goal (measured by velocity) for the whole team but the team couldn't do it because they are required to build the same piece of code?
If the team knew they couldn't do it, they shouldn't have agreed to that Sprint Goal in the first place. They knew they would not be able to make good on their commitment.
If on the other hand they didn't know they couldn't do it, and only learned so afterwards, this would indicate that the work was not ready, and that the Product Backlog refinement undertaken was inadequate.
what can I do if I have enough PBIs to achieve the Sprint Goal (measured by velocity)
The sprint goal describes how your product will deliver a better outcome for the customer/user.
Not a number of points.
"We will be able to display videos anywhere we can currently display jpgs (which will result in more sales)" may be a sprint goal. Indeed it may be an Epic that takes several sprints - with the first sprint being "Admin users can upload a video", another being "video can be displayed on a brand new web page that doesn't yet exist" and the final one being "the static image component can display any multimedia file for any logged in user."
Not a single mention of effort in any of those goals.
This is from the Scrum Guide's section on Sprint Planning
How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
The Developers know the technical limitations. They are the ones responsible for turning the Product Backlog Items(PBIs) into increments of value. They should be able to determine if PBIs can be done concurrent or not. The Product Owner has to respect their assessments. If during the execution of the Sprint, new information is discovered there should be a conversation among the Scrum Team on how to handle any changes that need to occur.
So if the team won't implement enough work during the sprint, we won't have any potentially releasable product increment or the Sprint Goal won't be achieved, right?
I do not remember reading anything that says everything in the Sprint Backlog has to be in support of the Sprint Goal. So if a team chooses items to support the Sprint Goal and feel that they still the capability of doing more work then they can pick additional items from the Product Backlog that can move them forward on a future initiative. The Sprint Backlog supports the Sprint Goal but doesn't have to be exclusive to the Sprint Goal.