User Story Splitting – Vague, General, or Generic Words
Another great way to approach splitting User Stories is by watching for vague, general, or generic words in stories.
Take this example from my fictional Recipe app:
What does “share” mean? Does the user want to text a link to someone, send a recipe via an email as an attachment, or do they want to post it on social media? If so, which one(s)? “Share” is far too vague in this story.
We can then take this as an opportunity to split this story into smaller ones – based on the specific activity they want to perform:
Now, in some ways, this breaks a cardinal rule of requirements: we as Business Analysts are trained to state the “what” without specifying the “how”. In this case, I think it’s acceptable to break this rule because these are very specific channels of performing the action of “sharing”. As “sharing” is too vague, we do need to spell out exactly what that verb means.
Questions to ask:
- Are there vague, general, or generic terms in your User Stories that need to be better described so they are more specific?
- Are there many ways of performing an activity/verb that are not well understood?
- Could you start with only one of the split-out stories, and defer others until later?
User Story Splitting – MVP (Minimal Viable Product) to Enhanced
What is MVP, you ask? Well, it stands for Minimal Viable Product. To boil that down, it entails identifying the aspects of the User Story that are a “must have” to make that story valuable enough to be released to the market to start gathering feedback. Once the MVP has been released, you can then iterate on your first release, creating stories that enhance the original “bare bones” version.
The important part of splitting stories this way is that it gives you a competitive advantage. The sooner you can release a usable product to the market, the faster you will get user feedback. The feedback you receive can then help drive future enhancements and provide input into prioritizing the Product Backlog.
A good example of this that I often see in agile training is the Agile Bicycle. However, that analogy is somewhat flawed. I recently read a blog that addresses the flaws of the original analogy. In the revised analogy, the User Story might go something like this:
As a person,
I want to get from point A to point B using my human energy, but without walking or running,
So I can get to where I want to go faster
What might be the absolutely must-have features of this device?
Hmm… maybe:
- Two wheels
- A way to connect the two wheels
- Something to sit on between the two wheels
In this first pass, the product would be very crude, but it could be used to propel a person forward in a straight line using the power of the legs, but with much less expenditure of energy. This would represent the MVP.
Future iterations would then enhance the original MVP, using feedback from users to drive additional User Stories in the Product Backlog.
A second iteration might include these additional features:
- A method to steer or change the direction of the front wheel so you can travel in curves, not just a straight line
- Something to rest your arms on
- A way to keep the device upright when not in motion
This makes for a slightly better bike.
A third iteration could add these features:
- A handlebar rather than an armrest
- A way to propel the bike without putting your feet on the ground (pedals)
And so forth…
One of my former clients was a famous bike manufacturer, and I can tell you that the bike continues to be improved upon. I got to work on their “smart bike” product, which added these features:
- A solar-powered human-machine interface (HMI, aka: a computer screen on the dash)
- A lock built into the bike
- Ability to lock and/or unlock the bike using the HMI with a password, an RFID card, or a mobile phone
- Voice- and screen-guided biking directions using bike paths
- GPS Trip tracking (map of your biking route)
- Distance, time, and calorie calculations
- Warnings if the bike needs maintenance
The next iteration of this bike was a motor-assisted smart bike, for use in cities like San Francisco where there are many steep hills, because it’s not always practical to use only human energy.
As you can see, the bike has come a long way from the original MVP. This is a fantastic way to start with a large, somewhat vague idea, pare it down to its most basic features, and then incrementally and iteratively enhance the original version to build a better product.
Questions to ask:
- What are the essential features needed to accomplish your user’s goal?
- What could be deferred until later?
- How important is it to be first to market or gather feedback quickly?
