ITIL, Project Management, Business Analyst, IT Management, Security, Radia, SCCM, McAfee, Windows
Thursday, February 5, 2015
How To Write Good Stories
How To Write Good Stories
Start with the Users
As its name suggests, 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, as the following picture illustrates
Use Personas to Discover the Right Stories
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. Simply ask yourself: What functionality does the product have to provide to meet the goal of the personas?
Write Stories Collaboratively
A user story is not a specification, but an 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.
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 modelled 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.
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: 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.
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.
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. As a rule of thumb, I like to use three to five criteria for detailed stories.
Use Paper Cards
Paper cards are not only cheap and easy to use. They facilitate collaboration: Every one 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 dependencies. Even if your stories are stored electronically, it is worthwhile to use paper cards when you write new stories.
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.
Don’t Solely Rely on User Stories
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