As its name suggests, a user story tells a story about a customer or user employing the product. Write therefore stories from the user’s perspective and show how a user or customer uses some product functionality.
2. Write user stories collaboratively
A user story is not a specification, but an communication and collaboration tool. Stories should not be handed off to the development team but be complemented by a conversation: Product owner and team should talk about stories, or even better, write them together: Invite the team to create and detail the stories together. This leverages the creativity and the knowledge of the team and usually results in better user stories.
3. 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 following template puts the user or customer into the story and makes its benefit explicit. But use the template only if it is helpful. Try out different ways to write your stories to understand what works best for you.
4. Start with epics
Epics are big, coarse-grained user stories. Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for new products and new features, as 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 to relate the feedback you receive to the right stories. I like to use the personas with their goals to discover the right epics.
5. Decompose your stories until they are ready
Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. Everyone 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.
6. Add acceptance criteria
As you decompose 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 the other stakeholders.
7. Group user stories into themes
Using themes helps you organise your stories. Each theme is a group of related stories. Sample themes for a mobile phone are email, calendar, voice communication, and organizer, for instance. Themes make it easier to check for completeness and consistency, they structure your product canvas or product backlog, and they facilitate prioritisation.
8. Use paper cards
Paper cards are not only cheap and easy to use. They facilitate collaboration, as everyone can take a card and jot down an idea. Cards can also be easily grouped on the table or wall to check for consistency and completeness. 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 communication 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 great 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. Also considerthe 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.