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, 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:
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:
To break out stories based on the happy vs unhappy path, I would start with the happy path:
Then the unhappy path story would then be:
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.
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:
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:
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.
