How to best split user stories.

What we are struggling with most is synching the work between all teams to ensure we meet our Sprint goal and finish deliverables.

One clarification: Do you have multiple teams or one cross functional Scrum Team?

I am happy to see you are using the Sprint Goal! Don't forget that your Scrum Team is also accountable for a valuable and useful product Increment every Sprint. That doesn't mean you have to release every Sprint, but that would be a plus.

Nonetheless the goal of the PBI should be focused on bringing value. I coach Scrum Teams to think about splitting vertically into small pieces (through the tech stack) rather than horizontally (by component). This way there are no dependencies, code is integrated and tested, and transparency isn't missing at the Sprint Review. After all is it transparent to your stakeholders if they are inspecting an Increment with a front end not hooked up yet to a backend? Would it be Done if it wasn't tested? No, and undone work is not presented at the Sprint Review.

Here is one splitting flowchart I have used with success.

https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/

All the best

What we are struggling with most is synching the work between all teams to ensure we meet our Sprint goal and finish deliverables.

@Chris and I zeroed in on the same quote.  A Scrum Team is not made up of representatives from different teams that coordinate work between those teams. A Scrum Team is made up of individuals that are capable of doing all the work necessary to satisfy changes needed to a Product.  

but if we split it further this would mean the QA will have to test the BE first then the FE and BE, and we want them to test once all is finalized. 

Only if you follow your strategy of splitting things in a horizontal matter so that it can be delivered in a waterfall manner.  If you were to split it vertically, you can delivery differently.  

Let's consider this example.  The Product needs to add a new function to allow users to enter, see, update, delete some inventory values. You are advocating splitting this horizontally where the Back End writes all the code to manage the actions, then the Front End writes the UI to allow users to fulfill the actions.  Why not split it horizontally?  First write all the code necessary for a user to view the information.  Then in a second Product Backlog Item deliver the ability to enter data.  A third Product Backlog Item could introduce the ability to update data.  Fourth item can introduce the deletion capability.  By doing this, you can show the first body of work to the stakeholders and gain valuable feedback. Are you showing them the correct information in a manner that they can easily read and comprehend?  Second one will get you feedback on the approach that was taken for traversing the fields, validating input, surfacing errors.  I think you can get the idea without me going into the third and fourth items.  After delivering each item, you have an opportunity to get feedback and adjust based upon that feedback for the next iteration. 

You have to stop thinking of each individual speciality as a team and start thinking of how each individual speciality is important to the work. This might require some organizational changes as well.  This is the opening statement of the Scrum Guide's section that describes the Scrum Team. (emphasis added by me)

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

I have a scrum team consisting of a UX Designer, QA, Front End, and Back end. 

I don't think you do. I think you've got a group of those people, but not a team, because teamwork is not being demonstrated. The composition of that so-called "team" is meaningless or unclear at best, as others have noted.

If there is no front-end work for example, a specialist apparently twiddles their thumbs. It does not occur to them to help a back end specialist, or to even start developing such skills. That's the problem. You won't find the solution by trying to split user stories between specialists. You may succeed in covering the problem up for a while, but that's all.

The solution lies in establishing the teamwork which is currently missing. So, what sense of urgency is being communicated and reinforced for the necessary changes to happen?

Thank you for the good insight. 

I think overall we are not intentionally splitting the work hirozontally, we try to deliver a feature/business value each sprint based on the goal we have set during the Planning. 

The way we achieve this is by splitting the user story into tasks and work on those in parallel. 

Problem might be that the team mind set is they either do FE or BE work. They do communicate well, but everyone looks only at their work and once their are done, they are looking for something else to take. 

Also yes, we are one Scrum team that is cross functional but the devs are limited on what they can do, they are not full stack, or they have interests in one area. 

We do try to implement best practices from the Scrum Guide, but not always succeed.