‘According to the INVEST principle, the requirement for a user story is that it must be “small enough” or have the right size. A user story should be sufficiently small that 6–10 of them can be done in a sprint. Of course this also depends on the speed of the development team. To achieve this goal in principle, a large story must be split accordingly.
Following are some of the techniques which will help user stories fit into “S” of INVEST ..
Simple method from Mike Cohn for almost every large user story to divide or make into smaller stories..
A research activity can give you the knowledge you need to split a complex story.
- Spike is a term used in agile software development. Spikes are small, prototypical implementations of a functionality that is typically used for the evaluation and feasibility of new technologies. This method involves investigations and building knowledge. It should be used if other SPIDR methods have not worked well.
- With the help of such newly acquired knowledge, some stories can then be better understood and possibly split more easily. This method, however, is relatively abstract and therefore harder to apply than the remaining methods.
If a user can do something in multiple ways, that’s a great area for splitting.
- If there are several possible alternative paths in a user story, one option is to create separate user stories from some of these paths. It is not absolutely necessary to write a story for each individual path, just where it makes sense.
- Example, let’s take a user story in which the user wants to be able to pay for purchases in an online store. There are now two possible paths: payment with a credit card or payment with Paypal. Payment with a credit card can theoretically be further subdivided, but you need to weigh up whether it makes sense for each type of credit card to have its own story. The overriding task of paying for purchases is, however, divided well into the two alternatives mentioned. Thus the newly created stories are smaller and more easily estimated.
Splitting your story by browser, or hardware, or deliver a complex interface in iterations.
- Interfaces in this context can for example be different devices or device types, such as smartphones powered by iOS or Android.
- User stories can also be split in terms of this diversity.
- Example of different operating systems: in a project, for example, there may be user stories that relate exclusively to the use of Android devices, or others that focus on web browsers. To avoid making stories too large and comprehensive, you should ask yourself which devices or interfaces you want to develop. Perhaps the first development result should only refer to iOS devices, because of the probably larger target group.
You may be able to deliver value in an iteration by focusing on one type of data
- Another technique for splitting user stories can be used when the initial stories refer only to a sub-range of the relevant data. Take the example of a website intended to attract tourists to a particular city. If it is a city known for its museums,
- Example, the first story could include information about the different museums in this area. A subsequent story could include various tourist tours through the city, and another deal with outdoor activities.
Relaxing support for the rules in an iteration can make large stories smaller.
- Business rules or technological standards can be another splitting factor. Take the example of online purchase of cinema tickets. There are often constraints that are for example based on business requirements of the respective cinema, such as an online purchase limit of a maximum of five tickets per e-mail address.
- With this story it would be conceivable that the development team omit this restriction, allowing every visitor to buy as many tickets as they wish. 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 can more quickly achieve a presentable result that satisfies the user or client. Omitted stories can be retrieved at a later date.
“Vertical slice” is a shorthand for “a work item that delivers a valuable change in system behavior such that you’ll probably have to touch multiple architectural layers to implement the change.” When you call the slice “done,” the system is observably more valuable to a user. This is contrasted with “horizontal slice,” which refers to a work item representing changes to one component or architectural layer that will need to be combined with changes to other components or layers to have observable value to users.
Workflow Steps Pattern
Suppose that a particular story is based on a well-established workflow. Thus this pattern splits the larger story along the lines of individual steps in the workflow, such as:
- As an author, I want to be able to submit my article.
- As an editor, I would like to get notified when an article has been submitted so that I can review it.
- As an editor, I need to approve an article.
- As an editor, I would like to be able to request more information.
Business Rule Variations Pattern
This pattern seeks to separate business rules that are present in a particular story, looking for opportunities to split the story based on differences between/among those business rules. Here are a couple of example business rules:
- Payment currency must be specific to purchase location
- Cash payment denomination amount must not be greater than . . .
- Payment change amount is calculated as . . .
- Receipt bar code is designed using . . .
With the simple/complex pattern, look for opportunities to modify a story that is very general (which often hides complexity). Attempting to define acceptance criteria for each piece helps to facilitate this process. For example, the story …
- As a loan applicant, I want to calculate my mortgage payments, so that I can decide which type of loan is right for me.
Might be made more specific by adding various ways the applicant could accomplish their goal, such as …
- … calculate payments manually
- … calculate payments using an online spreadsheet template
- … calculate payments using an online calculator
Variations in Data Pattern
In this pattern, the focus shifts to data objects. Work with the Product Owner to choose data object options based on user roles and actions. Suppose that there are data objects called Product, Payment, and Receipt. In this instance, the idea would be to focus on specific data types for each object type. So for Product, there might be data types such as Book, DVD, and Gift Card.
You can then work with the Product Owner to identify the data type or types with the highest business value and split the story accordingly.
Data Entry Pattern
Complexity sometimes hides in the user interface. In that case, split the story to build it with the simplest possible UI and then build the more usable or fancier UI later. These, of course, aren’t necessarily independent stories— the second story effectively is the original story if you do it first — but it still can be a useful split.
Thus a story such as
- As a traveler, I can search for flights between two destinations, so that I can decide which flight is best for me.
Could be broken out in different ways such as
- …using simple date input fields.
- …using simple destination input fields
- …using date input fields with validation
- …using destination input fields with validation
- …using a fancy date picker/calendar
- …using a fancy map-based destination picker
With this pattern, try focusing along the lines of operations and procedures. Some teams might look at this in terms of a CRUD (create-read-update-delete) scenario, such as this:
- As a shop keeper I want to manage the products being sold in my online store so that I can sell what people want to buy.
If the above story is still too big, it could be further split based on CRUD operations like this:
- As a shop keeper I want to add and remove products from my online store so that I can sell what people want to buy.
- As a shop keeper I want to edit product details in my online store so that I can avoid recreating a product to fix a typo … (and so on)
Another general rule of thumb is to watch for generic verbs such as “manage,” for example, “as a new student, I want to manage my account.” The word “manage” tends to conceal more specific actions such as “cancel an account,” edit an account,” and so on.
Defer Performance Pattern
In this pattern, the idea is to look for opportunities to defer work that is making an existing story inordinately large. Trying to achieve a particular performance target via a single story tends to result in larger stories. It is often best to look at system performance as a global constraint that needs to be addressed more broadly.
Here are some additional examples of “non-functional” requirements that are often best considered separately:
Break Out a Spike Pattern
A story may be large not because it’s complex, but because the implementation is poorly understood. In this case, no amount of talking about the business part of the story will allow you to break it up. Do a time-boxed spike first to resolve uncertainty around the implementation. Then, you can do the implementation at such a time when you’re in a better position to break it into smaller parts.
Consider the following story:
- As a purchaser, I can pay by credit card.
Such a story could first be investigated via spike, then subsequent pieces could be implemented, such as:
Spike: Choose a credit card processing approach
- As a first-time purchaser, I can enter my credit card info
- As a returning purchaser, I can use the credit card info stored in my profile
- As a returning purchaser, I can modify the credit card info stored in my profile
- … etc
In the “choose a credit card processing approach” spike, the acceptance criteria would typically consist of the questions that need to be answered. Do just enough investigation to answer the questions and stop; it’s easy to get carried away doing research.
The spike split is last because it should be your last resort. You probably know enough to build something. Do that, and you’ll know more. So, make every effort to use one of the previous eight patterns before resorting to the spike pattern.
Split by capabilities 
This is the most obvious way to split a large feature. Look at the different capabilities being offered and split each one into its own story. For example, the capabilities “sort and search” may each be its own story. Splitting further, each way of sorting or searching may be its own story.
Split by user roles
Administrators interact with a system differently from normal users. Teachers interact with instructional software differently from students. By defining the different roles in your system, you can split features and stories to address the unique needs of each role.
Split by user personas
Even in the same role, different people interact with software in different ways. A power user wants lots of keyboard shortcuts. A casual user may want a lot of intuitive, hold-your-hand forms of help. Handicapped users may need very different ways of interacting with the system, even though they are doing the same tasks as other users.
Split by target device
You can’t assume that users are interacting with your system using a standard computer. Various smartphones and IoT devices need to be considered in your stories. Splitting stories by device provides a more natural experience for your users.
Evaluate the split stories
Here are some questions you need to ask to determine whether the original story is split as well as it can be, and whether the post-split stories need further work:
- Are the post-split stories roughly equal in size? Yes/No. If No, consider applying a different pattern to split the original story, or choose a pattern with which to split any post-split story that is/are larger than the others.
- Do each of the post-split stories have all of the INVEST attributes? Yes/No.If No, consider applying a different pattern to split the original story, or refactor any of the post-split stories that need rework.
- Do any of the post-split stories reveal especially high-value or low-value work? Yes/No. If Yes, work with the Product Owner to determine whether the work in a post-split story is: a) higher in relative priority than other post-split stories; and b) necessary (sometimes the exercise of splitting stories reveals work that is not really necessary).
- How not to split : https://www.mountaingoatsoftware.com/blog/five-story-splitting-mistakes-and-how-to-stop-making-them