Capabilities/User Goals
This seems to be the most obvious approach to story splitting. If you’re just starting out with a vision or big ideas, then you need to figure out a way to make them smaller and more approachable so you can further decompose them into user stories that can be completed within a sprint.
What is a capability?
It is something the user can do – usually a feature or functionality (I will use these words interchangeably through this blog series, so make note). A capability is needed so the user can accomplish some goal. I’m going to use a fictional “recipe” application as my example in this series, so I hope you’re a fan of cooking, baking, or (if neither of those) eating. An example of a capability I might want to have in a recipe app could be:
That is a high-level capability, which I’m going to call a “Feature” – which is a big idea that could probably be broken down further into smaller “User Stories”. If I want to add recipes to my fictional app, what capabilities does the app need to have for me to get recipes into the app, and why do I need them? What am I ultimately trying to accomplish?
As a user of the recipe app, I want to be able to:
| Capability (what I want to do) | Goal (so that – why I want to do it) |
|---|---|
| manually add my own recipes to the app | I can view them on my device wherever I am |
| scan my recipes to add them to the app | I don’t have to manually enter them to get them into the app |
| upload my recipes to the app | I can bring all my recipes in at once without having to manually enter them |
| include a web address to add a recipe to the app | I can add recipes that I have tried (or want to try) to the app |
| include a picture of the completed recipe when I add a new recipe | I will know what the finished product looks like and have a visual reference when I’m looking at my recipes in the app |
| include tags when I add a new recipe | I can more easily categorize and find them in the app |
Etc…
The user’s primary goal is to get recipes into the app. If a story is too large, such as in the example above, then it can likely be broken down into sub-capabilities/sub-goals. You can see that these could just as easily be acceptance criteria for the large feature of “Add Recipes”, but they look distinct enough to me that I think this may be too large to do within a single sprint. Breaking them out into the smaller chunks will enable at least some of them to be done.
Questions to Ask:
- When you start to break out acceptance criteria for a story, is the list too long?
- If so, could those criteria be separate user stories?
- What functionalities or capabilities are needed to build out a large feature?
- Why does the user need these capabilities (i.e. what is their goal, or what are they trying to accomplish that necessitates the capability?)
A helpful way to break this down or to model these requirements would be the use of a hierarchical functional decomposition chart or a feature tree. Either one of these business analysis techniques could help you to split out the higher-level needs and break them down visually. This could also be used as a supplement or a guide to help you identify capability gaps as you write your user stories.
Splitting large stories into smaller sub-capabilities based on a user’s goals is a great first step in practicing story splitting. If you can get the hang of this, then you can move on to trying some other methods of story splitting.
Next, let’s look at how to split stories with Workflow Steps.
Workflow Steps
One common way to split stories is by workflow steps – in other words, the steps from beginning a process to the end.
Let’s revisit my fictional Recipe app that I want to add recipes to. Imagine there is a staff that manages the app; before anyone can publish a new recipe to the app, it must go through an approval process. The steps of that approval workflow might be another way to split out some user stories. Let’s say the large feature for this is:
The steps in the workflow might look like this:
- User submits a new recipe for approval to be published
- Editor reviews the recipe to ensure it doesn’t have any offensive language or photos
- If it’s OK, the Editor approves it
- If it’s not OK, the Editor rejects it and an email is sent to notify the submitter
- If approved, it goes to the Publisher who runs the recipe through a check to make sure the recipe isn’t copyrighted
- If it’s not copyrighted, the Publisher approves it and the recipe is published
- If it is copyrighted, the Publisher rejects it and an email is sent to notify the submitter
A great technique for modeling steps in a workflow is to create a workflow diagram like this:
Using these in combination, you can then use them to write user stories, as follows:
Etc.…
But don’t stop there. Continue to analyze.
Questions to Ask:
- Are there any steps that are unnecessary?
- Are there any steps that can be removed (albeit temporarily)?
- Can you start with the simplest workflow, and then progressively elaborate on it?
A first pass might be that there isn’t any approval process at all: as soon as a recipe is submitted, it is published. You might then layer on the first level of approval by the Editor and follow that up with the last steps by the Publisher. Maybe you decide that most people are not crass and wouldn’t submit anything inappropriate, so you skip the editorial review step.
Can you see how these two techniques are useful for splitting your stories?
