This concept was first espoused by Bill Wake, in 2003. He says:
A story needs to be valuable. We don't care about value to just anybody; it needs to be valuable to the customer. This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer.
When we split a story, we're serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it "right"); but a full database layer (for example) has little value to the customer if there's no presentation layer.

It is true that many teams struggle to split large user stories into smaller stories in a useful way, but, fortunately, story splitting is a skill that can be learned in a relatively short time. There are now several techniques and tools that can be used to split user stories. I would like to introduce you to the simple and fast SPIDR method from Mike Cohn (Agile coach and co-founder of the Scrum Alliance). He summarizes five techniques with which almost every large user story can be divided.

SPIKE
If the subject on a User Story is not clear or too complex and needs extra research, it’s time for a Spike.
A goal of a Spike can be gaining more information on the topic by doing research or it can be gaining experience on the subject by building a prototype, typically used for the evaluation and feasibility of new technologies. With the help of such newly acquired knowledge, a story can then be better understood and possibly split more easily with other SPIDR methods.

PATH
If there are several possible alternative paths (or scenarios) in a User Story, one option is to create separate User Stories for some of the paths.
For example, let's take a User Story in which the shop owner wants to send the customer his new password by text message or email in case the customer forgets his password. You can split the User Story into two separate paths to recover the customers password.
It is not absolutely necessary to write a story for each individual path, just where it makes sense.

INTERFACE
Interfaces in this context can be different devices, for example if you have a website and an app. It might be useful to split a User Story into separate stories for the different interfaces, you might change the website first, because of the probably larger target group, and after that the app.

DATA
If a User Story needs more than one source of data for all requested functionality, you can often start with only one source of data.
For example, if you are building a website intended to attract tourists to a particular city, the first story could include information about the different museums. After that you can add hotels, public transport options, outdoor activities, etc.

RULES
Business rules or technological standards can be another splitting factor. Take the example of online purchase of items. There are often constraints that are for example based on business requirements of the respective shop, such as an online purchase limit of a maximum of 3 items per basket (similarly to dry pasta and toilet rolls limit during coronavirus pandemic). With the first User Story it would be conceivable that the development team omit this restriction, allowing every user to buy as many items as they wish, not considering the purchase limit. The restriction could then be added in a second iteration step. Incremental delivery such as this means that initial stories are not immediately implemented completely, but instead are delivered in several smaller steps. Sometimes it makes sense to neglect technical specifications or business rules, if by doing so you are able to discuss the early results with the stakeholders.

User Story splitting is not always easy at the beginning, but practice makes it perfect.

Source:
This post was inspired by SPIDR – five simple techniques for a perfectly split user story