Product managers are expected to cultivate and maintain relationships with numerous people during the development process. The most intimate of these, however, will be with the product user. You should know them inside out: who they are, their preferences, and their needs. One way to develop and maintain this relationship is by writing user stories.
Just like manifestoes and vision documents, user stories are an integral part of product development. Good user stories are the key to driving efficient planning and delivery, team engagement, and customer satisfaction. Vague user stories often indicate that the team will struggle to complete tasks further down the line—something I have witnessed often in my role as a product manager.
My involvement in successful startups—and some that have failed—has shown me firsthand the importance of taking the time to craft quality user stories. This guide will help you and your team master each element and write quality user stories time and time again.
What Is a User Story?
A user story is a small increment of the product represented in terms of the value it will offer to the end user. A group of user stories creates an epic, and a single product can comprise multiple epics. A user story can be broken down further into tasks that more accurately reflect the work and outline how the story will be completed. User stories generally employ the formula User – Functionality – Benefit, which can be applied effectively to most industries and businesses.
Typically, the product manager is responsible for writing user stories, but occasionally this may fall to the product owner, Scrum master, or engineering manager. Ideally, every user story will be reviewed by the person, or people, who will undertake the work.
What Are the Benefits of a Good User Story?
A good user story has several benefits for the team and product:
- Defining the “who” and writing from the user’s perspective ensures that focus is maintained on the customer, rather than on what the team wants or prefers.
- Defining the “what” clarifies the criteria for the person completing the task, known as the doer. Anything that’s not in the story can be considered out of scope.
- Defining the “why” motivates the doer by helping them understand the impact the deliverable will have on the user’s life.
- Defining user value can help identify a less-beneficial feature before work on it begins—and resources are potentially wasted.
What Does a Good User Story Look Like?
If, for example, you are building a house for your customer, one of your stories would be about creating the enclosing walls. A bad user story might say “I need walls”—identifying the “what” but nothing more. A better one would be: “As a homeowner, I want my house to have enclosing walls to keep out the elements, and so the roof doesn’t fall on my head.” I believe, though, that if a user story is truly fulfilling its purpose, it should clearly and concisely answer all of the following questions:
- Who is the user?
- What does the user want? Why does the user want this?
- How should the engineering team interpret this story?
- Does this story depend on another story being completed beforehand?
- Does the completion of this story enable another story in the backlog?
- What is the scope (i.e., what are the minimum criteria)?
- How big is this story (i.e., where does it fall on the estimation scale)?
This is the template I use—it has evolved with my product management knowledge and worked well for me for many years:
Component | Question | Answer | Purpose |
|---|---|---|---|
User Persona | Who is the user? | The user is a rich man from Chicago who is building a luxurious summer home in the Hamptons. | To fully envision the user, teams work with many different personas, so it is important to be as detailed as possible. |
User Story | What does the user want? Why does the user want this? | “As a homeowner, I would like to have decorative brick walls around my home in a diagonal basketweave pattern because I will see them every day and would like them to be a pleasing sight.” | To understand the motivation of the user and their reasoning. |
Summary | How should the engineering team interpret this story? | The user wants elaborate walls, so we need to build a regular central wall and then have scaffolding in the required style (i.e., diagonal basketweave). We can use regular bricks for the core wall, but will need to use high-quality decor bricks for the facade layers on both sides of the wall. | To break down the story logically into tasks, which aids progress-tracking. |
Precondition | Does this story depend on another story being completed beforehand? | In order to start work on this, the foundation of the house needs to be completed and ready to build upon. | To interpret where a story is in the workstream hierarchy and visualize the overall delivery timeline. |
Postcondition | Does the completion of this story enable another story in the backlog? | When the walls are completed, we will be able to put up support columns and, finally, the roof. | To interpret where a story is in the workstream hierarchy and visualize the overall delivery timeline. |
Definition of Done | What is the scope? | There should be a continuous set of exterior walls around the house, with a diagonal basketweave-style facade on both sides of the wall. End-to-end width of the wall should be no less than 12 inches at any point. | To define when a story is complete. The solution will need to include everything listed here. |
T-shirt Size | How big is this story? | Medium | To loosely estimate delivery time for the overall story. A more granular estimation will then be completed for each task by the doer. |
A Common User Story Myth
When it comes to judging whether user stories are good or bad, there is a pervasive myth that I want to dispel.
Many people believe that a user story should be completed in a single sprint, and, if it isn’t, it was a bad user story. This is not the case. Of course, it is preferable that a user story gets completed in a sprint (and this should be achievable), but the team’s bandwidth and external factors may impact the amount of work that can be done—and this will vary from sprint to sprint. Also, estimates generally assume that every development team member has the same skill level across all domains; the fact is, it will take less time for a more experienced engineer to complete a task than a junior engineer.
You shouldn’t try to craft short user stories just so that they will be completed quickly; rather, your user story should seek to represent a logical increment of value delivered. Don’t let a schedule dictate your creation of a compelling user story.
Keep the User Front and Center in Your Mind
I find projects are most enjoyable and most successful when I am confident in my knowledge of the user—you can learn more about my experiences on my personal blog. Whether I’m pitching new features or deciding on the scope of delivery with my team, knowing what the user would say is the most reliable way to test my vision. It is, however, easy to lose touch with the user—and therefore the “why”—if I’m not regularly thinking of them. This is true for the majority of product managers whose focus is often pulled to other tasks and duties. Writing good user stories can help you and your team members maintain that image of the user in your mind, and even enhance your relationship with them.