Why we have to split User Stories?
The most obvious reason for splitting a user story into smaller ones is that the size is too big to be implemented in one Sprint. This is realized after the estimation process the team did for this user story.
Big User Stories are often named as Themes and Epics. Usually the biggest is the Theme which includes Epics which includes User Stories.
Let me clarify here that it doesn't mean that every User Story that it has to be split is an Epic or a Theme. It may be just a User Story that it is too large to fit in a Sprint or the amount of space that it is left for the next Sprint cannot include a User Story as it is so it must be split.
Themes, Epics and User Stories Relation
Before going to user stories split up, lets see some examples of what can we call a theme an epic an a user story. Epics and Themes by default most of the times will be split without any input from the team because probably the PO knows that they are already too big.
User Management - Theme Example
An example of a Theme could be:
"As a system I want to provide the ability to Administrators and Users to Manage Profiles so every administrator will be able to create,update,delete users and their profiles and every user will be able to update his profile only. For the administrators it will possible to assign authorizations to users in order to give them access in specific resources. Administrators and Users will be able to upload pictures in their profiles. Also everyone will be able to reset his password but the Administrator will be able to reset other Users password. Finally the Administrator will be able to enable or disable a user. Various fields will be supported in each profile such as Firstname, Lastname, Email (locked), Birthdate... etc."
In above example the reason that it can be named as Theme is that it is describing the total user management functionality of a system. This has some perspectives. One is the Administrator perspective and another one is from simple User perspective. Every role can do different things but all are related to user management.
Usually to identify Themes you should look for gathered features that affect a wide area of the system.
User Management - Epics Example
Keeping the above Theme of User Management lets specify some Epics for it.
"As an Administrator I want to have an administration screen to control every action for the users. This screen must contain a search area to find users. Search filters so I could search more easily and action buttons on each result row. On double click I want to be able to see the users profile. Other actions in every result row should be a) Give authorizations b) Deactivate User c) Reset Password. The first action should redirect to a screen which the user is pre-selected and below there are all his already given authorization. From there I want to have options to remove or add more authorizations... etc"
"As a User I want to have a user screen so I could change my settings. I want to be able to upload my picture, reset my password, edit my personal information fields and save. Also I want to be able to see my actions history in the system resources. From there I want to be able to search them using filters such as date and action type... etc"
So we see that every perspective of the theme can generate Epics. Usually to identify Epics you should look for gathered features to a specific area of the system.
User Management - User Stories Example
Lets use the first Epic from above to extract some user stories.
"As an Administrator I want to be able to search other users so I could find them. I want to have a search bar to place a search term. The search term should accept special characters such as *. The term should look in the fields: username, firstname, lastname, email. On the left of the screen I want to have filters on the results: a) Given Authorizations Filter b) Department Filter c) Created From and To Date Filter"
"As an Administrator I want to have the Activate-Deactivate Option on a result row from the search so I could active and deactivate a user easily. When a click deactivate the user will not be able to login anymore. If she is already logged in then no action on resource will be permitted and if she try she will be redirected to the login screen."
You can see that when you examine an Epic User Stories appear. At least if the Epic is well written. Usually to identify a User Story look for a feature which affects a small area of the system.
Most of the times, the PO will realize what can be called a Theme or an Epic and that these must be split to smaller pieces. If this is not obvious then the need will be realized during the estimation process which is done by the team. Next we see ways that the team could decide to split big user stories.
Avoiding meeting (from the beginning) the non functional requirements
If you have non functional and functional requirements in a user story try to remove the non functional from the user story. For example you may have the constraint of the time of search response from the server to be under 1 second. You should deal with these performance issue later and create for example a "Increase Search Performance" user story. Initially you should focus to make things work and give value to the customer by providing him a feature that will change his way of using the system.
Select data boundaries
Lets suppose you have a User Story which describes a big form in which the user can enter many fields in order to do his tax declaration. This form has an enormous number of fields that they must be filled. Try to find related small areas in the form that they could be described as a user story. Of course at the end of the Sprint the entire tax declaration will not be releasable for production since the user needs all fields to submit his declaration. From the other hand it shows progress and also gives the opportunity for early feedback. This early feedback could be a guide of how the rest of the form will look like.
Select operational boundaries
Given the above example of User Management from the administrator screen, we can easily realize that a potential big user story could be the "Create, Update, Delete, Activate/Deactivate" actions that the administrator can perform on users. We could create a User story per action since each one of them gives an isolated feature to the customer and its more easy to fit in a Sprint than the doubt which creates by having them all in one User Story.
Remove systemwide requirements
Systemwide requirements are those which affects almost all the system. For example the logging and the authorization. You may have the requirement that in a specific screen the user with role X will be able to see some extra fields or perform extra actions. if you have initially implemented this kind of support in the system such as Authentication and Authorization infrastructure then go ahead and include it in the story. But if not, its preferable to give something that works for every user role or at least for the user who his operations gives the most value to the customer and let the authorization support for another user story.
Some user stories may contain multiple points which give to the user the power to perform new actions on the system. You should try to identify priorities inside these points and create corresponding users stories if you feel that taking it as a total user story may not fit in the Sprint. Priorities mean that these actions will give the best value for the customer than the remaining in the story.
The splits though should make sense for the customer and you must be careful not to split by tasks.