When splitting user stories, we should always split them vertically as if we are slicing a piece of cake. The whole cake is a cake and each vertical slice is a piece of cake with all it’s layers. A horizontal slice might just have the icing, or maybe just the filling, or just the crust and does not make for a very tasty cake. Similarly, stories should represent some level of end to end functionality. Splitting stories into smaller stories like design, create data model, code the front end, code the middle tier, code the back end, integrate, test, will result in no value delivered until all stories are completed. These are all tasks that we must do but it’s important not to split our stories this way. It is always better to deliver a cohesive subset of all layers of a feature than delivering all of one layer as a standalone. Having the entire backend ready without a corresponding GUI is not very useful and vice versa. However, having a feature that allows the user to add an entity through the GUI and have it trigger some business functionality and persist data is functionality that can be useful and provides value. This approach reduces overall risk by continuously integrating different parts and ensuring constant delivery of customer value.
So here are 5 main techniques for splitting a user story:
Data Boundaries: Deliver functionality for a subset of data first before adding more options. For example, separate local requirements from international requirement, or handling one type of credit card from another, or start with supporting USD then add foreign currencies.
Operational Boundaries: This typically is done along CRUD boundaries where for example a story is split into 3; one to create an entity, one to retrieve and modify or update, and one to delete the entity. Perhaps later add the ability to multi select and delete. Another example might be separating a story into search which simply returns search result count and then another story to return the actual results of the search. Another option is to tackle happy path scenarios 1st then add different stories for exception cases.
Cross Cutting Concern: Features that effect multiple aspects of the application like security, logging, error handling can each be separated out of main functionality features. For example, a screen that will have different menu options or links based on the login user’s credentials. This security specific feature can be split from the main functionality of the screen.
Performance constraints: Functional requirement from nonfunctional requirements can be split into separate stories. For example, a feature can be enabled without caching and then another story can handle caching specifics.
Priority: Within a story, there might be multiple priorities. For example, a login story might have different priorities for authentication than for handling error conditions like locking out a user after multiple logins.
According to Jeff Patton, a good way to look at priority is to consider Necessity first, followed by Flexibility, Safety, and then Comfort:
- Necessity: The minimum needed to get working software.
- Flexibility: Alternative ways of doing the same thing. Additional data we want to capture.
- Safety: Better validation rule to avoid ugly error messages.
- Comfort, Luxury, and Performance: More usable, Sexier to look at (animation), Hot keys.
To learn more about user stories, check out the entire Art of Storytelling Series:
- What is a User Story?
- Top 5 Advantages of User Stories
- The 6 Attributes of Effective User Stories – INVEST
- Top 3 Reasons to Split a User Story
- What’s the Right Size for a User Story
- Top 5 Techniques for Splitting a User Story
- What’s the Most Important Part of a User Story?
- 9 User Story Smells and Anti-patterns
- The Art of Storytelling – User Story Smells and Anti-patterns Presentation
Reference and recommend resource: User Stories Applied by Mike Cohn
