How George Costanza, Frogger and a Craving for Sushi Explain Features & User Stories
[Note: This is a more concise version an article that originally appeared on my blog. Full version can be found here.]
Scenario
It’s lunch time and you’re hungry. You decide on sushi for lunch - your feature is “Get some tasty sushi to eat for lunch.”
Our User Stories
You can break this process into several incremental steps - these are our 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: If the GIF does not display correctly, please go here.
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 up stories 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).
[Note: This is a more concise version an article that originally appeared on my blog. Full version can be found here.]