Back to List

Agile Story Splitting by Happy/Unhappy Paths & Operations (CRUD)

Rachael Wilterdink Rachael Wilterdink  |  
Mar 03, 2020
In this blog series, Rachael Wilterdink (CBAP, PMI-PBA, PSM I, CSM) dives into 25 different techniques for approaching story splitting that she has used throughout her career. Make sure to subscribe to our blog or stop by each week to catch all 25!

#3 - Happy / Unhappy Path or Flow

Good User Stories and Acceptance Criteria will address both the happy and unhappy paths of the story.
But what is a “happy path” anyway? (FYI - some also refer to this as “Happy Day”, “Sunny Day” or “Golden Path”). Whatever you choose to call it, it represents the perfect situation where there are few (or no options) and nothing ever goes wrong.
It stands to reason then, that the “Unhappy Path” is the opposite and includes any alternative or exception paths that might be possible. (NOTE: this is Use Case terminology)
A great business analysis tool to model or depict the possible paths in a flow is an Activity Diagram (UML). This model resembles the workflow diagram (from my previous blog), but it ignores the users and simply follows the flow of activities.

Example of a Happy / Unhappy Path

Let’s assume that, for my fictional recipe app, users must have an account with the system before they can submit new recipes for publishing.
The happy path for getting into the system would be that the user already has an account, knows their credentials, enters them correctly, the system authenticates the user, and they can access the system.
An example of an unhappy path might be that the user has an account, but they entered their credentials incorrectly and therefore can’t access the system. Here’s what this would look like in an activity diagram:
happy unhappy path
A couple more examples of unhappy paths in this scenario might be that the user doesn’t have an account yet or wants to recover a forgotten username or password (not included in the diagram above).
You can probably see how these types of diagrams can be useful but can also become complicated in proportion to process complexity, and the number of splits, exceptions, or alternate paths.
To use this method to split my stories, my big story would be:
happy unhappy path login

To break out stories based on the happy vs unhappy path, I would start with the happy path:
happy unhappy path success

Then the unhappy path story would then be:
happy unhappy path failure

Once you have identified both happy and unhappy path stories, continue to analyze.

Questions to Ask:

  • Can you split out the "happy" or sunny path from any unhappy, exception, or alternative paths in a flow?
  • Do you really need to account for all the unhappy paths to start with, or can they wait?
  • Are there any unhappy or alternative paths that can be eliminated? (think very rare use cases)
Asking these questions will help you determine your priorities.
If you can’t complete both the happy and unhappy path scenarios within a sprint, you can easily split and develop them over multiple sprints. But if you can complete everything in one sprint, perhaps you don’t need to split them out as separate stories. Instead, they become part of the acceptance criteria of a single story. There’s no right or wrong here – just what you can complete within in an iteration.
I find this to be a very handy (and easy) way to split stories if they’re too big.

#4 - Operations (CRUD)

In software development, most features include the standard operations of "Create", "Read", "Update", and "Delete". Whenever you hear or see the word "Manage", it's a clue that this might be an operational process.
This is another straight-forward way to split out your user stories. Continuing with my fictional recipe app, let’s suppose there is a feature that lets the user keep an inventory of items in their pantries for making recipes, and that the user wants to be able to manage the pantry items as they use ingredients up, or buy new groceries, change brands, etc. The big story in this example would be:
operations crud pantry

Let’s also assume in this example that it’s simple and that users can perform basic operations to:
  • View the items in their pantry
  • Add an item to the pantry
  • Remove an item from the pantry
  • Edit an item in the pantry
Based on this alone, I’ve clearly split the functions along operational lines. On occasion, it might make sense to combine some of these rather than keep them separate.
One example that I frequently run into is View/Edit. These are very similar. The main difference is that, in view mode, you can’t change anything. But I can argue that it’s sometimes better to split them because perhaps there are fields in edit mode that can’t be changed, and it can start to muck up the works if you combine these two activities.
So, given that we are splitting by operations, our stories would look like this:
operations crud view pantry
operations crud add items
operations crud edit items
operations crud delete items

Once you’ve split out your stories, be sure to stop and continue to think about whether this is the best way to split your stories.

Questions to Ask:

  • Can you start with just the "Create" story, and split out the "Read", "Update", and "Delete" into separate stories?
  • Do you really need all the operations? (Maybe the user always uses the same brands and would never need to edit the title or description of items – do you really need to give the user the capability of editing that?)
  • Does it make logical sense to combine any of the operations, such as View/Edit (especially if the user can edit everything and there is virtually no difference between them, other than the ability to edit and save?)
This is a great way to split stories in a very logical manner that everyone will clearly understand. This method is one that I use on almost every project or product I work on. If you haven’t used this approach before, give it a try and let me know what you think.


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Blog Article
20 Ways to Adapt Agile Best Practices to Remote Work
Rachael WilterdinkRachael Wilterdink  |  
Mar 24, 2020
The author of our Basic and Advanced Agile Transformation eBooks shares how you can adapt agile best practices to enable your workforce to be effective working remotely from home, the beach, or anywhere in the world (with reliable internet).   With COVID-19 disrupting nearly every aspect...
Blog Article
6 Real Truths About Project Leadership Learned from Trial & Error
Kari VondracekKari Vondracek  |  
Mar 17, 2020
About the author: Kari Vondracek (MBA, CSM, PMP, PSM I) is a project manager at Skyline Technologies. Since 1996 she has been leading projects in a variety of industries. When I was a young, know-it-all, 25-year-old, I was put into my first managerial position. I was a fresh college...
Blog Article
Agile User Story Splitting by User Roles
Rachael WilterdinkRachael Wilterdink  |  
Mar 10, 2020
In this blog series, Rachael Wilterdink (CBAP, PMI-PBA, PSM I, CSM) dives into 25 different techniques for approaching story splitting that she has used throughout her career. Make sure to subscribe to our blog or stop by each week to catch all 25!   Different users of your...
Blog Article
Agile Story Splitting by Capabilities/User Goals & Workflow Steps
Rachael WilterdinkRachael Wilterdink  |  
Feb 18, 2020
In this blog series, Rachael Wilterdink (CBAP, PMI-PBA, PSM I, CSM) dives into 25 different techniques for approaching story splitting that she has used throughout her career. Make sure to subscribe to our blog or stop by each week to catch all 25!   #1 - Capabilities/User Goals ...
Blog Article
How to Identify Good and Bad Agile User Stories
Rachael WilterdinkRachael Wilterdink  |  
Feb 11, 2020
If you read my previous blog, you’ll know the basics of a User Story. But what makes for a good or bad agile user story? In this blog, I’ll cover the criteria that will help you identify one from the other.   What Makes a Good User Story? The most common checklist that is...