Stories Have Multiple Granularities
User stories may seem like they are about specifications but they’re really a lightweight way to explore possibilities.
Many teams get too focused on the “card” aspect, using tools to turn user stories into an atomized requirements spec.
Instead, we can use stories to think fluidly at multiple levels.
Scenarios and Conversations
At a high level, we tell stories about problems and about how the world might be. These are not little atomized bits of “As a shopper, I want to search for dog toys so I can find something to buy.” Instead, they create a richer view.
We’ll use LinkedIn.com for examples. (This is a reverse-engineering exercise; I have no inside knowledge about how they envision, think about, or implement their systems. Instead, I’ve looked at the system as a user and reconstructed stories I might have used.)
A vision:
What if you could make your professional network explicit? Find people you’ve worked with or met, and explicitly connect to them. You might look at their acquaintances, and try to link to some of those people too. When lots of people connect, most anybody is only a few links away.
Sending a Message – the old way:
You met someone at a conference. It’s not somebody you really keep in touch with, but something has come up where you’d value their advice. You traded some email maybe 3 years ago. You try to email them but it bounces. You search online a bit without really finding them; maybe you could ask around and see if another friend knows them. But that is a lot of work for a casual question.
Instead…
What if you met someone at a conference, and accepted an invitation from them when you got home. When you have a question they could help with, you find them in your network, and send them a message. You don’t have to know their email address, so you don’t care that it changed. You get a reply a few minutes later.
(and many more stories…)
LinkedIn has many more parts than this, but we can imagine a series of scenarios – stories (in the English-language sense) – about a better world.
These stories (and the conversations that go with them) are much richer than the typical user story.
Given such stories, we can explore: Are we describing problems anybody cares about? How might we address them? Who would value this capability?
We can make decisions: What is most critical? Who is it for? What is most important (to users, to others, to ourselves)? Is the system coherent? Does it align with our vision?
We can search for themes, knowledge, and activities that occur: network, links, connections, messages, searching, …
Capabilities and Headlines
User stories can help us move from ideas toward implementation.
We can move to smaller stories that describe capabilities the solution must have. We’ll certainly continue to have conversations.
I think of these smaller stories as starting out as “headlines”. I mentally add “(somehow)” to them as I’m not yet worried about details about how they would work (though I do want them to be feasible).
You can take the headlines, and walk through your earlier, richer scenarios to check that what you’re thinking of addresses what you intend.
Here are some headlines for a key subset of the LinkedIn functionality:
- System displays connections
- User searches for a connection
- User connects to another user
- User sends message
LinkedIn has many more capabilities, but these headlines describe a coherent part, and were present early on.
This coherence is important. If you could make connections, but not see or use them, what would be the point?
Notice how sending a message leverages connections and provides a benefit related to one of the vision ideas above: you don’t have to keep up with someone’s current email address.
Teams sometimes skip this level and go right into the next (details) level. This hurts – headline level allows for many solutions; jumping into a particular detailed version locks in a single solution.
Details
As we narrow in on how things will work, we can add details to our headlines.
The most common way I see this done is having bullet points that are a checklist of everything that must be done, like this:
Headline
- Detail 1
- Detail 2
- Detail 3
- :
(There are other ways to do this; we’ll explore that another time.)
Let’s add some details to one story: (You might have sketches or other things too)
| System displays connections – List connections – Selecting a name goes to that person’s “home” page – Filter by name – Sort by recently added – Sort by first name – Sort by last name – Filter by other alternatives (as when finding a connection) |
Ultimately, we want to be able to connect any of these details back to our larger, more vision-oriented stories, for the impact they have.
Conclusion
Many teams lock in on small-grained stories too early. You can do do better:
- Have wide-ranging “scenario” conversations
- Help the whole team explore the vision and possibilities
- Separate headline-level thinking from detail-level thinking to increase your flexibility and creativity