A user story is a scenario, a description of a (potential) real use of a system. It takes the customer or user perspective, and represents a team’s shared understanding of what the system should do.
Because stories take a customer perspective, you can plan with them as a whole team, driven by customer needs. Because stories describe behaviors or qualities of the system, developers can grow the system a bit at a time. Once an early version of the system becomes useful, each following version becomes even more useful.
Stories can be kept fairly small – days of work to at most a couple weeks. You can start small and enhance, or start larger and split the stories down.
The Three C’s
Ron Jeffries describes user stories as 3 C’s: Card, Conversation, and Confirmation. (See References.) Ron was the coach for the first XP team; XP is the Agile process that introduced stories.
Card: An index card with a summary headline and a sentence or two of explanation. For example, a store might have a story with the headline “Shopper adds item to cart”, and a note saying to update the item count and total cost.
Conversation: The core – a discussion among the whole team about what is wanted and possible solutions.
Confirmation: Test ideas, perhaps even test cases, that can help confirm that what was built satisfies what was wanted.
A card is not a specification – it’s way too limited for that. Alistair Cockburn describes a card as a “promise for a conversation” – a reminder.
Using User Stories
When you’re using stories, reinforce the connection to higher-level goals. (Too many teams don’t understand how what they do fits together, or how it accomplishes what’s desired.)
Focus on critical needs first. There’s often a Pareto curve: 20% of effort may give 80% of results. Critical needs also help drive the software toward a robust solution. If the user has a slow or manual process today, any level of automation is likely to have a big impact.
Work toward an early release. Multiple small releases help you maximize feedback and learning. We often have a lot to learn: Do we understand the problem? Are we creating a feasible solution? Do the users and/or customers value our solution?
Tools and Templates
When you’re starting, there’s a temptation to dive into tools and templates.
The most popular tools are “agile project management tools”. Their sweet spot is when you have lots of distributed teams and many, many stories. That is not the place to start. In fact, going there at any time should give you pause. (You may have to, but resist if you can.)
If you can, start with index cards. Most coaches I know agree with this. (Some will say – just use cards, and only use a tool at the bare minimum level to meet corporate needs.)
The most common templates are those for headlines, and of those, the most popular is “As a type of user, I want to do something so that some goal is met.” A simpler form is one Industrial Logic suggests: Role-Action-Context, e.g., “Travel agent reserves ticket with a credit card”. There are others too.
But you don’t need a template to start – it’s ok to write down whatever brief phrase will remind you of the story. But if you think a template will help, there’s nothing wrong with using it. Remember, a template helps with the Card, but the Conversation is key.
I prefer scalable stories, where the same headline works for a series of solutions. Clarity at the high level helps you stay linked to your goals. Your early stories can be minimal, and then you can create more sophisticated capabilities as the system grows.
If your project is big, and you find yourself talking about a number of stories, you may find it helpful to create a story map. To use this, lay out the stories with the most important ones nearer the top, and organized horizontally more or less in the order users would use them. See Jeff Patton’s book in the References.
Who and What?
Who creates stories? The conversation is for the whole team – you want ideas from product people, testers, programmers, UX, possibly users/customers – basically anybody in your product community that can contribute.
It’s common for there to be someone from the product side who makes sure the conversations happen and the story cards are written. In other teams, the whole team jointly takes responsibility.
What are stories about? That’s up to you. The two most common styles are stories about “functional” behavior (what the system does) and “quality attributes” (how well the system does it). For example, in an email system, “user sends a message” is a functional behavior, and how quickly and how reliably it happens are quality attributes.
In general, make your stories about things that customers and users care about. If you make them about things team members care about (but customers/users don’t), it’s hard to make tradeoffs. Many things a team does can be tied back to customer-valued stories. Ones that don’t usually don’t need to be stories.
For example, I want teams to refactor their code, but that is just “how we work”, not a story. Another example, I don’t want meetings to be stories. They’re a way to collaborate, not a goal of business.
Alternatives to Stories
-or – Why prefer stories?
Stories aren’t the only possible way of handling things. I prefer stories in most cases, because they tie to customer needs, encourage us to reduce work, deliver faster, and learn faster. But you may need to be aware of other approaches. We’ll look at two: classic requirement specifications, and pseudo user stories.
Alternative 1: Classic Requirement Specifications
A common alternative approach (especially when XP started) is a requirements specification (“spec”), typically where one or more analysts work with customers to identify the “requirements” to address a problem (and too often, also describe a half-baked solution).
They’d document all these ideas – typically representing months or even years of work – in a large document (often hundreds of pages or more in medium to large projects).
Challenges
- It’s hard to explain what’s needed in a clear, concise, consistent, and complete way, all in advance. Instead, inconsistencies, ambiguities, and misinterpretations are common.
- “Requirements” documents often mix in a fair bit of “solution” too. This makes the document longer and more confusing, and limits creative solutions.
- There’s a tendency to try to get “everything” in – who knows when you’ll get another chance? This makes change expensive, and hard to understand what’s critical.
- The process is unstable: needs change over the time it takes to deliver, and using the new software changes the needs.
Comparison with User Stories
The big difference with user stories is that stories focus on conversation. This forces a time shift – rather than spending weeks or months creating a requirement specification before development and delivery, that time is spent in conversation during.
This lets us move toward delivery sooner. We needn’t wait for every need to be identified, just the most important ones that we can start addressing.
You can’t remember all the details for months of work, so you have an incentive to reduce “work in progress” (WIP). Smaller batches are delivered more quickly.
Less WIP also makes it easier to change direction – you’ve invested less to get there, and there’s less of a feeling of sunk cost.
We reduce ambiguities and other problems through conversation and confirmation. By having a discussion, it’s easier to be sure we agree on what’s wanted. By agreeing on test ideas, we move to concrete answers about what’s wanted.
Because user stories help shorten the time between identifying a need and addressing it, we also benefit from feedback. We can find out many things: “That’s what I wanted, but it’s not what I really need”, so we adjust. A little tweak might make our solution much more effective or valuable. We discover holes in our conversations and confirmations, and can use that to do even better in the future.
Alternative 2: Pseudo User Stories
I hate to have to address this, but there are many teams out there using what they call “user stories” that don’t mean anything like what I described above.
Most commonly, in Ron’s terms, they’ve reduced or eliminated the Conversation, and over-focused on the Card. They have some of the form of stories, but the approach creates barriers that block many of the benefits of conversation-oriented user stories:
- Delay between writing stories and addressing them. With so much in the pipeline, increased WIP means longer to deliver, and even less chance for conversation and feedback.
- Hundreds of stories in the backlog. It’s hard to see what’s important. It’s hard to change direction (since any change may affect many other stories, in addition to the sunk cost fallacy). This also creates the need for a tool, and for processes around it.
- Mini-specs rather than a headline and a couple sentences. It takes longer to create them, creates an illusion of completeness, and substitutes documentation for conversation.
- Backlogs of tasks rather than stories. It’s common for these backlogs to end up with many tasks – things the team must do as part of adding a capability or feature. But customers can’t steer based on tasks: they often don’t understand a task or why it’s needed, so it reduces their sense of control and their ability to control.
- Stories split across teams. Delivering a capability may require several teams to each deliver their piece. Often, there’s nobody responsible for making sure the whole capability works. This also introduces planning complications. I’m pretty sure I’m not the first person to think of the Tetris™ game, but for planning.
If you can’t remember the conversation when it’s time to develop the story, or it never happened, you’re taking a different approach.
Further Study
User stories were introduced by Kent Beck, in Extreme Programming Explained (linked to 2/e). (I relate stories to scenario-based design in HCI, although I don’t think I’ve heard Kent claim this inspiration.) In addition to Jeff Patton’s book, Mike Cohn’s book User Stories Applied has been popular too.
For websites, I’ll use my author’s privilege and recommend my own site: in particular, xp123.com/invest and xp123.com/articles/tag/user-stories/ . You’ll find articles on the INVEST acronym, scaling and splitting stories, examples, and more. There are certainly other sites out there too:)
For a good next article, read “Intensifying Stories” from the References. Or reach out to me, bill@xp123.com – I’m happy to discuss stories with you.
References
“Essential XP: Card, Conversation, Confirmation”, by Ron Jeffries. Retrieved 2021-09-27.
“Intensifying Stories: Running with the Winners“, by Bill Wake. Retrieved 2021-10-04.
User Story Mapping, by Jeff Patton with Peter Economy. O’Reilly, 2014.