A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. User stories typically follow a simple template:
Historically user stories were deliberately kept informal, written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. Their impermanence made it easy to tear them up, throw them away, and replace them with new stories as more was learned about the product being developed.
Nowadays, user stories might just as easily be stored in a Project Management tool, or a Knowledge Management tool (e.g., Notion). Don't let the fact that a user story exists in a tool make you any less willing to discard stories when they are no longer needed!
User stories are designed to strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
What Is a Good User Story?
Agile user stories are composed of three aspects: card, conversation, and confirmation
- Card: Written description of the story, used for planning and as a reminder
- Conversation: Conversations about the story that serve to flesh out the details of the story
- Confirmation: Tests that convey and document details that can be used to determine when a story is complete. User stories have many advantages, but the most important might be that every user story is a placeholder for a future conversation.
How to write a user story
Writing good user stories in Scrum requires an understanding of the basic user story template, a focus on the user or customer, and a clear picture of the desired functionality.
User Story Template
When writing a user story, remember that user stories follow a standard template:
Examples of User Stories
One of the best ways to learn how to write a user story in agile is to see examples. Below is an example user story or two. These are a few real examples of user stories that describe the desired functionality in an early version of the Scrum Alliance website.
- As a site member, I can fill out an application to become a Certified Scrum Trainer so that I can teach Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) courses and certify others.
- As a trainer, I want my profile to list my upcoming classes and include a link to a detailed page about each so that prospective attendees can find my courses.
- As a site visitor, I can access old news that is no longer on the home page, so I can access things I remember from the past or that others mention to me.
- As a site visitor, I can see a list of all upcoming “Certification Courses” and can page through them if there are a lot, so I can choose the best course for me.
Note that you don't see any user story, "As a product owner, I want a list of certification courses so that..." The product owner is an essential stakeholder, but is not the end user/customer. When creating user stories, it's best to be as specific as possible about the type of user.
Julien’s notes
What I really like about user stories is that it forces us to distinguish the feature request from its expected benefit. This allows us to validate whether the feature request is the optimal way to deliver the expected benefit. The person who identifies the need is indeed not always the one who is aware of the multiple ways to serve that need.