Summary
User stories are probably the most popular agile technique to capture product functionality: Working with user stories is easy. But writing good stories can be hard. The following ten tips help you create good stories.
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, ans 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.
Learn More
Learn how to write effective user stories and improve your user story writing practice by attending my Writing Great User Stories Workshop.
| Reference: | 10 Tips for Writing Good User Stories from our JCG partner Roman Pichler at the Pichler’s blog blog. |
