French translation
S is for Small in the INVEST acronym. I now use another S that I think captures the idea even better: Scalable.
Scalable means “able to be changed in size or scale,” and that’s handy in a story: We want stories sized to what we’re trying to do.
It’s helpful to think about stories at three levels: high, medium, and low.
High-Level Stories: Themes and Activities
The highest level view helps us learn the shape and extent of the system we need.
These items are so big that most people don’t even call them stories. You may know them as “themes” (Kent Beck), “activities” (Jeff Patton), “epics” (SaFE), or “kite level” (Alistair Cockburn). (We’ll ignore the subtle differences.)
For example, suppose we’re creating a new car rental system. We might talk about:
- Reserving cars
- Renting cars
- Returning cars
- Analytics
As we look at this list, we may realize we haven’t thought about “Loss and Damage”: what happens if a car is stolen or damaged? Perhaps the concept should be “Fleet Management,” and include prepping cars.
I’m not a car rental expert, so surely there are other major areas of the system. But it’ll be closer to a dozen than a hundred at this level.
These aren’t stories somebody can just go implement. We use these to answer, “Have we forgotten anything big?”
Middle Level: The Headline
The middle level is where stories’ headlines are. This is the level of story maps and release plans.
For a headline to make sense, we have to talk about a particular kind of story: External and Valuable. Such stories start from outside a system, and describe a user or system action that accomplishes something a stakeholder cares about.
Headlines don’t need to follow a template, but I default to the one Industrial Logic suggests: Role-Action-Context:
- Role – the user or system triggering the story
- Action – what happens
- Context [optional] – when, where, and/or how
Example: Customer purchases item
Example: Customer purchases item with debit card
Some teams create headlines and stories that are super-detailed, but only cover part of a system action. Don’t do that; make your stories describe a full (though possibly small) and valuable interaction. Keep the details a level down.
Ironically, people sometimes create and excuse these partial “technical stories” (ugh) as their way to keep stories Small. They may be small, but they’re not user stories. A Product Owner can’t work with them effectively.
but they’re not user stories.
Stories that users value and that can scale up or down provide a lot of power in an Agile delivery model. If we can assemble the most critical stories and deliver them in a minimalistic way, we can quickly get a working version of the system. (See Alistair Cockburn’s idea of a Walking Skeleton.)
Once the system is working, even if in a clunky way, we can start using it, while we simultaneously enhance it over time as usage scales. This may get us early payment (yay!) but will certainly give us early feedback.
We need feedback because… like it or not, we’re ignorant. We have theories about what’s valuable, but we’ve never put them to the test. We build a house of cards out of our assumptions. (Read about Minimum Viable Products too.)
I’m sure there are domains where Product Owners exactly understand the value, but I don’t run into them. Where I go, people tend to have limited data about usage, sales, etc. Even when they have data about what users and customers do, they tend to guess about the future and about what would appeal to non-users and non-customers.
Low Level: The Details
At the bottom, we care about how we do things.
For example: Customer purchases item
This story can be delivered in many ways.
For example, I used to buy soda water cartridges from a website where you just emailed them a purchase request, including your phone number in the email. Then Joe called you to get your payment info and shipping details.
Other ways this story might work:
- In a physical store, a customer might ask the clerk for an item. The clerk pulls it from the shelf behind them, hand-writes a receipt with a carbon copy, gives you the item and the original receipt, and sticks the carbon copy on a spike.
- In a supermarket, a customer might walk through the store, put the items they want in a cart, then check out with clerks at registers in the front of the store. Some grocery stores have a self-checkout, where you scan your own items.
- When you buy something at Amazon.com, you have your credit card on file, and Amazon attempts to cross-sell and up-sell while you check out. (Your purchase also feeds a lot of reports and analytics, perhaps described in other stories.)
A single headline allows for many variations. That is scalability in stories.
We’re used to different stores doing things differently, but we sometimes forget that our own implementations can evolve as well.
You may recognize this approach as being iterative. It’s iterative not just in the software implementation, but also in the details of the story.
Scalability and Splitting
One headline covers many potential stories.
You may already be used to the idea of splitting stories. Given a story, the team comes back and says, “This story is too big—we need a smaller bite.”
But splitting is painful: you build up a full description of a story, with all the capabilities and ideas you imagine for it. Then the team takes a scalpel, knife, or sledgehammer to it, tearing it apart.
The process can drive a product owner to tears.
This is where Scalability comes in. Think of the intensity of a story as a dial: skeletal, minimal, natural, elaborate, excessive. (These are fuzzy, not definitive levels.)
Move from splitting stories to intensifying stories.
to intensifying stories.
As a product owner, work from the scaling-up perspective. Start small — smaller than you might expect — and grow your stories over time as you deliver.
How Big?
Big stories are tricky.
- It’s hard to know we’ve got exactly the right features (as we’re adding things without a lot of experience).
- Big stories often mix both more and less valuable parts, so it’s hard to separate out their contribution.
- Big stories strain the delivery team to digest and deliver a big chunk of work.
You may have learned to make stories that are MMFs: Minimal Marketable Features. But even that’s too big in a continuous-delivery world. Instead, think of Minimum Useful Features – small things that still makes somebody’s life a little better (and can grow into big things).
For example, consider an improvement in a search engine: the user interface stays the same, but search results are a little better. This is worth releasing even if it doesn’t merit bullet points in an ad.
I’ve often encouraged people to make stories smaller – hours to days of effort, not weeks to months.
Can stories get too small? Definitely. I like Jeff Patton’s analogy of overly-atomized stories as a bag of leaves, stripped of structure and burying you in details.
How can you deal with too-small stories? Merge them. (This is one reason I like the “major” headline view – you can have stories that cover different details, then generalize and merge them to talk about the headline and the current state of implementation.)
Unfortunately, many “agile” planning tools take a hierarchical, atomized view, and don’t help much when thinking in terms of scalable stories. It takes work to maintain the big picture.
Conclusion
John Gall said, “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” It’s a good reminder for stories.
Remember the three levels from earlier:
- Theme – Top-level: Are we covering the right things?
- Headline – Mid-level: Is the user getting a capability they care about?
- Details – Lowlevel: Do we need a new capability, or can we improve an old one?
Rather than splitting too-big stories, train yourself to start with smaller versions, then extend and intensify them. If you have to split, take a user’s perspective, not a technology perspective.
You will find that scalable stories will:
- Help make progress visible
- Provide early utility
- Give you feedback that helps you steer to a more valuable result
- Help reduce market and technical risk