Ten Techniques That Can Make a Good User Story

Roman Pichler reports:

"[A] user story describes how a customer or a user employs the product. You should therefore tell the stories from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific piece of functionality such as searching for a product or making a booking...A great way to capture your insights about the users and customers is to use personas. But there is more to it: The persona goals help you discover your stories...What functionality does the product have to provide to meet the goal of the personas?...A user story is not a specification, but [a] communication and collaboration tool. Stories should never be handed off to the development team. They should rather be part of a conversation: The product owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories...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 modelled [sic] as a persona into the story and makes its benefit explicit. Use the template when it is helpful, but don’t feel obliged to apply it. Experiment with different ways to write your stories to understand what works best for you and your team...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: 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...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 [be] too big, and there has to be an effective way to determine if the story is done...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 [ensure] that the story can be demoed or released to the users and the other stakeholders...Paper cards are not only cheap and easy to use. They facilitate collaboration: [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 and to visualise [sic] dependencies. Even if your stories are stored electronically, it is worthwhile to use paper cards when you write new stories...Stories want to communicate information...Make them visible instead...Creating a great user experience (UX) requires more than writing user stories. 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."