In classes I teach, there is often confusion between what is a feature and what is a user story. This article is a simple analogy (a quest for sushi) that helps to explain:
- The difference between a feature and user story.
- How user stories can be broken into incremental chunks.
- Why George Costanza is not agile.
Simple Definitions of Feature and User Story
My simple definition is that a
- Feature: Realises full, end-to-end value for the end user (aka true value).
- User Story: Adds system value via incremental, fully tested, “banked” chunks of functionality that get us closer to realising feature value (but has no end user value in isolation).
Occasionally you can achieve end-to-end user value with a single story which is great but unusual (e.g. adding additional validation to an existing user input field to prevent end user data capture errors).
Scenario
You’re visiting your company’s London office but cannot buy lunch in the office cafeteria because they only accept payment via special “cash pre-loaded” cards. Your friendly London colleagues keep offering to buy you lunch on their cards but they won’t accept your cash in return and you don’t want to keep sponging off them. Besides which, you are in the mood for sushi and have been eyeing out a restaurant 500m from the office on your stroll into work each morning.
Our Feature
You need to eat and have a craving for sushi – so this becomes our highest priority feature: “Get some tasty sushi to eat for lunch”. Our feature achievement (or acceptance criterion) is met when: “I have my lunch in hand” (or in chop sticks if I’m coordinated enough).
Our User Stories
Our feature can be broken down into several smaller, incremental steps (no pun intended) which are our user stories. Unless I’ve done something stupid (like forget my wallet back in the office), the completion of each user story allows me to “save game” and I won’t need to retrace any steps.
If we wanted to be really pedantic we could consider each step to be a user story as it gets us incrementally closer to our feature achievement – but since we’re pragmatists, we’ll go with the following user stories:
- “Go from desk to building entrance”
- “Go from building entrance to busy road”
- “Get across busy road”
- “Go from busy road to sushi shop”
- “Select sushi”
- “Pay for sushi” and
- “Eat sushi”.
Note: In software development stories are not usually as straightforward and linear as this but for simplicity’s sake let’s play along.
Splitting Stories in Smaller Chunks
Let’s focus on the “Get across busy road” story. Crossing a busy road can be tricky because we’ve got to wait for both lanes of traffic to be completely clear before we can cross the road.
This is perhaps the most dangerous, risky and unpredictable step in our journey. The feature may take a total of 5 minutes to complete if everything goes well but this might increase substantially if we spend a long time waiting for both lanes of bidirectional traffic to be clear of cars and bicycles (peddlers are the silent assassins to the unwary pedestrian).
Luckily, our architects have done a good job designing our system (see picture below) which enables us to split the user story into two because the dependency on both lanes being clear has been decoupled:
- “Get across first lane”
- “Get across second lane”
This reduces the risk, improves our flow and increases our velocity as we can cross the first lane without worrying about cars in the second lane. Once we’ve crossed lane one, we can “save game” and only then need to worry about lane two – waiting until it is safe to cross before heading into the sushi shop.
It also prevents us having a George Constanza “Frogger” moment (see below).
Note for millennials: If you don’t know who George Costanza is and have never watched Seinfeld then you’ve got some treat catch-up watching to do!
We then select and pay for our sushi and complete our feature – hopefully having a satisfying lunch that will sustain us for the rest of the work day.
Summary
Each story had a “system benefit” that got us incrementally closer to realising the feature or “end user” benefit. However, it is only when the collection of stories has been completed that we get the real “end user” benefit.
We increase the probability of realising the feature benefit by:
- Breaking stories up into small manageable chunks so that we can “save game” as frequently as possible.
- Only doing the stories that directly relate to the feature and doing them as quickly as possible (in case a pointy-head boss calls us back to office before we’ve got our lunch).
- Architecting our system to minimise risk and maximise flow (so we don’t end up in ER after being squashed by a demented cyclist – they don’t serve sushi in hospitals).
Afterword
Just in case anyone gets the wrong idea that I spent the whole time in the UK eating, I did manage to run two marathons during the 10-day trip: for me marathons are the most important features to achieve during a business trip!
You can read about them here:
- Clarendon Marathon (An epic tale of mud, marathon running and jelly beans)
- Phoenix “Numbers Game” Marathon (Mixing with UK’s Lunatic Running Fringe)
Some Further Reading
This is a really interesting article about how using good design for traffic calming is much more effective than warning signs. It’s much easier to drive good behaviour with good design than by trying to control behaviour with rules.
“Shared Space – the alternative approach to calming traffic”
I also recommend you take a look at my article on “The Power of Feature Hypotheses“.
Follow Running Mann:
