In the world of agile development, user stories have become a central part of product management. But the concept of user stories can easily be misunderstood to be just another way of outlining the requirements for a product or a service. If you don’t pay attention to writing user stories, you might end up wasting your time and be left with ill-fitting stories.
© pixabay | Unsplash
In this guide, we’ll explain the concept of a user story and examine the qualities that make up a good user story. We’ll then provide you with six tips for writing exquisite stories and finally detail the limitations of a user story in product management.
USER STORY IN A NUTSHELL
User story is a concept used in software development and product management. It is a description of the user using the products, as well as an explanation on what the user wants from it and why. In it’s essence, a user story helps to create a more simplified requirement description.
User stories are essential for building your service, whether a software or a product, as they help identify the needs of the user. Instead of using lengthy requirement specifications, user stories can help capture the core elements of the functionality.
To put it shortly, a good user story will capture:
- The who – who is using the product or service?
- The what – what are they trying to achieve with the product or service?
- The why – for what purpose are they using the product?
One of the simplest user story templates would look like this:
As a [who], I want to [what], so I can [why].
Therefore, a user story for a recruitment website might be:
As a job seeker, I want to search for a job, so I can get on the career ladder.
User stories are generally used as part of agile development strategies, with the product manager taking charge of the creation. Nonetheless, it’s a good idea to ensure everyone in a team knows how to write user stories and to use them for the benefit of the project.
WHAT MAKES A GOOD USER STORY?
While the concept of a user story is straightforward, writing good user stories is not as easy as you might think. There are good and bad user stories. Before we look at the tips for writing good user stories, it’s beneficial to first examine the reasons behind a good user story.
One of the most commonly cited ways to assess the strength of a user story is with the INVEST acronym. The acronym was first introduced by Bill Wake, the author of eXtreme Programming Explored, and it’s a great method to test if your user story is well written.
INVEST stands for:
- Independent – each feature should be as independent as possible.
- Negotiable – user stories are not detailed specifications, but tools for the team to discuss and collaborate.
- Valuable – user stories must provide value to the user of the product or service.
- Estimable – user stories don’t need to include too much detail, but they must provide enough information so that you can make estimations.
- Small – user stories are not big, but small and concise.
- Testable – the wording must allow the user story to be tested.
When writing user stories, it is helpful to keep the above acronym in mind. It can help you capture the essence of a good user story: it’s a story, not a task.
Finally, it’s important to understand what a user story is not supposed to be in order to create a solid story. You are not writing a detailed specification of the product or service, when you are creating a user story. A user story will start a conversation and help move the team forward, not end it as a final description.
TIPS FOR WRITING GOOD USER STORIES
In order to ensure your user stories follow the INVEST concept and help you fulfill the business needs, keep the below tips in mind when writing user stories.
Research your user
It’s essential to first understand who the user is. After all, user story should be written from the user’s perspectives and you can’t capture the what and the why, if you don’t start with the who.
Interview and observe the user to understand who they are and how they are using the product. You can’t write a good user story by speculating on the user and their ideas – you need to research these before. In short, you are examining the functionality of the product and service in terms of the user.
Therefore, you want to create user personas as a way to capture the user in more detail. A user persona can consist the following elements:
- A name and a picture
- Relevant characteristics and personality traits
- Attitude of the person
- The benefit of using the product or service
Let’s consider the following examples of a user story:
- As a user I want to be able to access job postings so that I can find work.
- As a job seeker I want to be able to access job postings so that I can find work.
The examples are similar in nature, but the first doesn’t define the user well enough. We don’t know the user persona and we cannot make further assumptions, when he is only referred to as ‘the user’.
On the other hand, the latter example defines the user in detail and instantly gives us more information about what the user needs.
Learn from Google Ventures on how to conduct a user test.
Start with epics
You should start the process of writing user stories by creating epics. An epic is a big and sketchy story, which will break into smaller, separate user stories over time.
By creating epics first, you can develop an understanding of the functionality better and leverage user feedback on the prototypes. With an epic, you’ll learn about the needs of the user and how to address them.
As you craft sketchy epics, you can start creating the detailed user stories. In short, epics can help you understand the user persona and parts of the functionality they are looking for. For example:
- As Kate, I want to tell people about big events at work.
As you learn more about the what and the why, you can start forging the above information into a more testable and clear user story. For instance:
- As product manager Kate, I want to show an overview of the upcoming events at work, so that I can promote them.
Focus on the goal
The key to a good user story is to focus on the specific goal. If you are able to identify the goal for the user, then you are going to understand the functionality of your product or service better.
There are two reasons goal matters in user stories. First, they ensure you are solving an actual problem with the user story and not simply assuming things. Second, they provide you the tools for testing the user story and understanding when the user needs are satisfied.
Therefore, in order to write a good user story, you need to consider why the user wants the specific feature or product.
For instance, the below example of a user story does not explain the value of the system in a clear manner:
- As a customer ordering groceries, I want to view my previous shoe orders on the website.
If you read the example, you are left asking what is the reason for the user wanting to see the orders. What is the value in being able to view the order history?
A much better user story would therefore be:
- As a customer ordering groceries, I want to view my previous shoe orders, so that I can re-order my favorite products faster.
This time you know what’s driving the user need. You are able to understand the customer behavior better and ultimately to test the user story’s viability.
Keep it concise
Pay attention to the language you use when you write user stories. Your user stories must be easy to understand. After a person reads a user story, you don’t want them to be left with confusion.
To achieve the right kind of tone you want to use an active voice and easy words. Jargon and a formal tone are not suitable for a user story. For instance, consider the following example of a complex and badly worded user story:
- As a customer, I need to save, print and email my lists on the platform, and then send the requirements for the shop.
The above is hard to read, it’s not concise and it doesn’t answer the question of why. In addition, it also includes a larger story and would be much better as an epic than a user story.
An example of a concise user story would be:
- As a customer of the food delivery service, I need to save my item list, so that I can use it as a starting list at the store.
You might also notice from the too examples that while the first example included a lot of detail, the latter example removed certain elements. In the above example, you probably would come up with a number of different user stories from the first epic.
While you don’t want the user story to include too much information, you also don’t want it to be too broad. Consider the example of:
- A member can manage tasks.
While the user story is short enough, it’s vague and doesn’t reveal anything interesting or valuable to the reader. Instead, you’d want to include more detail and say:
- As a team member, I can view or hide the tasks so that I can manage my account.
The example template mentioned in the introduction is one of the simplest templates to use. Whilst it is often the preferred format, you can experiment with other styles, as long as you pay attention to the length and clarity of the format.
Include acceptance criteria
A user story should always include acceptance criteria. The acceptance criteria are also known as Conditions of Satisfactions (CoS) or Definition of Done (DoD). This essentially helps underline the conditions for job achieved and helps with testing the user story.
Acceptance criteria can be used as a checklist to check the product or service has met the user’s need. You can create the acceptance criteria by asking questions such as:
- What if?
Your project should include between two to five acceptance criteria. You should create the list during a meeting with the product or service owner and the development team (if separate).
For example, if you are developing a service for registering membership, you’re acceptance criteria for user stories would be:
- The user knows how to register on the website
- The user knows how to confirm registration
- The user knows where to solve registration problems
Once you have the acceptance criteria, you can use it to test and support your user story. Remember the criteria is not there to restate the story, incorporate in new stories or contain new workflows.
For instance, if your user story is:
- As an app user, I want to delete messages, so that I can control my phone memory.
Bad acceptance criteria for the above would be something like:
- The user wants to select any message, remove the text and save another version of the text.
The problem with the above criteria is that it adds new workflows and stories to the existing user story. The user story doesn’t, for instance, mention anything about the ability to save modified messages.
Make it a team effort
As mentioned in the introduction, user stories are often the responsibility of the project manager. But the effort of creating them should solely rely on the hands of a single team member. The best user stories are created as a team effort because it guarantees they capture the experience and functionality better.
Roman Pichler recommends writing user stories as part of the backlog grooming process, as this guarantees the whole team can provide input for the stories. Furthermore, approach the writing process more through communication rather than implementation. You want the team to discuss the ideas, provide feedback on existing epics and data, for instance.
Even if you can’t have the whole team and all the relevant stakeholders meet at the same time, you should gather feedback from everyone.
Below is a great video on how to brainstorm user stories together with your team; outlining the steps, you need to make the most of the collaborative effort:
KNOW WHEN A USER STORY IS NOT ACCEPTABLE
In order to write good user stories, you should understand they aren’t always the right or the only format you should use as part of product management. There are a handful of business needs, which cannot be appropriately understood through a user story.
A user story might not be adequate format, if the product or service at hand is focusing on:
- A change request
- A constraint such as technology stack or database use
- A technical requirement such as a security standard compliance
For example, if you only need to capture a technical requirement, a user story won’t help communicate the problem and the solution. Ronica Roth, an Agile coach and consultant with CA Agile Central Software, said in her blog post that by trying to make a technical task into a user story, “you often do not end up with working software at the end of each iteration, and you lose flexibility in prioritization”.
If the why is a technical capability, you are generally better off avoiding a user story. This is because the technical capability is not going to provide value to the end user. Consider the following attempt of a user story with a technical capability as the why:
- As a tester, I want to have detailed plans so that as the system is completed, I will be able to test it.
Overall, user stories are just a part of a good user experience. But you also want to add in other techniques such as story maps and mock-ups. Remember user stories are not detailed requirement stories, but aimed at capturing the functionality of the product or service.
User stories are an essential part of product development. A good story can help understand the needs of the user and the ways the product or service can help fulfill them. It can guide product development by helping it focus on functionality.
Although the concept and purpose of user stories is simple, writing a good user story isn’t necessarily as easy as it sounds. Apply the INVEST approach to your user stories and remember to write the stories from the user’s perspective. Approach the process through communication and collaboration and be aware of the limitations of user stories.
Image credit: pixabay | Unsplash underCC0 Public Domain.
1. Users Come First
As its name suggests, a user story describes how a customer or user employs the product; it is written from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific functionality, such as searching for a product or making a booking. The following picture illustrates the relationship between the user, the story, and the product functionality.
If you don’t know who the users and customers are and why they would want to use the product, then you should not write user stories. Carry out the necessary user research first, for example, by observing and interviewing users. Otherwise, you take the risk of writing speculative stories that are based on beliefs and ideas — but not on relevant knowledge.
2. Use Personas to Discover the Right Stories
A great way to capture your insights about the users and customers is writing personas. Personas are fictional characters that usually consist of a name and a picture; relevant characteristics, behaviours, and attitudes; and a goal. The goal is the benefit the persona wants to achieve, or the problem the character wants to see solved by using the product. But there is more to it: The persona goals help you discover the right stories: Ask yourself what functionality the product should provide to meet the goals of the personas, as I explain in my post From Personas to User Stories.
You can download a handy template to describe your personas from romanpichler.com/tools/persona-template.
3. Write Stories Collaboratively
A user story is not a specification, but an communication and collaboration tool. Stories should never be handed off to a development team. Instead, they should be embedded in a conversation: The product owner and the team should discuss the stories together. You can take this further and write stories collaboratively, for instance, as part of your product backlog grooming process. This leverages the creativity and the knowledge of the team and results in better user stories.
4. Keep Your Stories Simple and Concise
Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what’s important, and leave out non-essential information. The template puts the user or customer modelled as a persona into the story and makes its benefit explicit. (It is based on by Rachel Davies’ popular template, but I have replaced user role with persona name to connect the story with the relevant persona.)
As <persona> ,
I want <what?>
so that <why?>.
Use the template when it is helpful, but don’t feel obliged to always apply it. Experiment with different ways to write your stories to understand what works best for you and your team.
5. Start With Epics
An epic is a big, sketchy, coarse-grained story. It is typically broken into several user stories over time—leveraging the user feedback on early prototypes and product increments. You can think of it as a placeholder for proper, detailed user stories.
Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for describing new products and new features: It allows you to capture the rough scope, and it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights. If you have lots of detailed stories, then it’s often tricky and time-consuming to relate any feedback to the right stories and you have to be careful not to introduce inconsistencies.
6. Refine the Stories Until They Are Ready
Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. All development team members should have a shared understanding of the story’s meaning; the story should not too big, and there has to be an effective way to determine if the story is done.
7. Add Acceptance Criteria
As you break epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the story’s narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story and make it more precise and testable, and they ensures that the story can be demoed or released to the users and other stakeholders. As a rule of thumb, I like to use three to five acceptance criteria for detailed stories.
8. Use Paper Cards
User stories emerged in Extreme Programming (XP), and the early XP literature talks about story cards rather than user stories. There is a simple reason: People used to write user stories on paper cards. This approach provide three benefits: First, paper cards are cheap and easy to use. Second, they facilitate collaboration: Every one can take a card and jot down an idea. Third, cards can be easily grouped on the table or wall to check for consistency and completeness and to visualise dependencies. Even if your stories are stored electronically, it is worthwhile to use paper cards when you write new stories.
9. Keep Your Stories Visible and Accessible
Stories want to communicate information. Don’t hide them on a network drive, the corporate intranet jungle, or a licensed tool. Make them visible instead, for instance, by putting them up on the wall. A handy tool to discover, visualise, and manage your stories is my Product Canvas.
10. Don’t Solely Rely On User Stories
Creating a great user experience (UX) requires more than writing user stories. You should also consider the user journeys and interactions, the visual design, and the nonfunctional properties of your product. This results in a holistic description that makes it easier to identify risks and assumptions, and it increases the chances of creating a product with the right user experience.
Additionally, user stories are not well suited to describe technical requirements, as they describe the product from the perspective of the user. If you need to capture technical requirements that communicate what an architectural element like a component or service should do, then write technical stories or — which is my preference — use a modeling language like UML.