By many, Mike Cohn is considered the godfather of User Stories. He has published books and frequently hosts webinars on this topic. He has also created a set of five techniques which he formalized in the SPIDR format.
Five techniques in SPIDR
The five powerful ways of splitting a User Story are:
These techniques represent the most frequently used to split User Stories and are short-listed from the list of story splitting techniques.
Let’s review these five techniques:
A spike is frequently used by Agile teams for the feasibility and evaluation of new technologies before building a new functionality. Often, part of the complexity of a User Story derives from the need to research, experiment with, and learn a new technology, rather than using it to build a new functionality.
Therefore, using the Spikes method, you could split the User Story by separating the learning and research part from the functionality building. One story covers the spike, and the other story covers the functionality to be built into the product.
Using the Spikes method can be effective to separate the effort required to learn a new technology and experimenting with it. It helps to split User Stories into simpler and less complex activities.
Whenever a functionality supports multiple choices or steps in its workflow, the Paths technique helps to separate each choice, or each step in the workflow, into a different User Story.
For example, consider an online store. You could have a User Story that describes a new functionality to let the customer pay for their purchases online. The functionality includes several possible options for the payment as the customer can pay with credit card, debit card, PayPal, or Cashapp. The payment with credit card may may have other subdivisions to support the different types of cards accepted (Visa, Mastercard, and American Express).
This story can be quite big, and you could split it by separating each option into its own story. You don’t need to build the whole thing at once, and you could start by building a check out option with Paypal alone. Later, you could add support for Visa credit cards. Then, you will add support for other payment methods.
Hence, you can split the original story into smaller ones, where each story only supports a specific path that the user can follow in the system. This method also allows to reduce complexity, and to build a new functionality incrementally.
A way to get started with this method is to draw on paper the flowchart of the process that your customers take through the system. Each step in the workflow can be supported by a User Story. Also, whenever a step can be implemented with multiple options (the flip chart splits into multiple paths), each path can be implemented with a separate User Story.
The Interface method can be used in a couple of contexts:
1 – The app you are building needs to support different OS (for example, Android and IOS) or different browsers (for example, Chrome, Edge, and Safari). Instead of building the functionality for all systems at once, you can implement it for one system at a time. For example, you could build the Android version first, test it, and then later decide to support IOS as well.
2 – You can build the functionality using a simple UI design first, and then add design complexity later. For example, instead of fancy icons that your users can drag across the screen to make a selection, you could first build a simple drown-down menu to help them make a selection. Then, add the fancy icons in a later story.
When the initial story needs to cover multiple types of data, this technique could be used to split the User Story. Let us consider an example of a website that is intended to map touristic places in a particular location. This website needs to support multiple types of places, for example hotels, resorts, restaurants, and museums. You can use the different data types to split the original story into smaller stories.
For example, you could build the map functionality first only for restaurants. Once this is built and works well, you can add hotels and resorts, and later museums. Each of these data types can be supported in a different User Story.
Another splitting technique for User Stories is based on identifying and separating the different business rules that the story must support. You may build a first version of the new functionality with only a limited set of rules, and you can later expand it with the remaining rules.
For example, if you are building a system to purchase concert tickets or cinema tickets, there could be several rules you may want to support. Often, these business rules represent constraints on what the customers can or cannot do. One such constraint could be to limit the number of tickets that a single person can buy. Let’s say that you have a business rules that allows to buy only a maximum of six tickets per person.
If you are building the online purchase functionality, you could first build it without any restrictions. You relax the business rules.
However, the restriction on the number of tickets purchased could be introduced in the next iteration. This process supports incremental development where the initial story provides the full functionality without restrictions, and the following stories add the support for business rules.
Sometimes, by neglecting the technical complexity in supporting business rules and constraints, you can build the product faster. The omitted stories could be added in the next iterations to enhance the product value.
Smaller User Stories help the developers build new functionalities faster and reduce the complexity. The five techniques in the SPIDR format are applicable to a variety of use cases and can be practiced to develop confidence, before venturing into using a broader set of techniques.