User Stories Guide
What are they?
User stories are value-focused units of delivery that are typically used in Agile projects. Written from the customer or stakeholder’s perspective, user stories share what is needed and why. The “who” in a user story is typically someone with a particular role or title, or it could be from the perspective of a persona: a fictitious, sample user’s behaviors and needs, spelled out in detail. When choosing the “who”, avoid being too general (e.g. “As a user...”) which defeats the purpose of pinpointing the value for your target audience. Write all stories with the “who” included, even those stories that are very technical.

Template
The user story template is designed to help Product Owners and others tell stories with a clear “who”, “what” and “why”. As a registered user, I want to reset my password, so that I can get back into the site if I forget my password. As an unregistered user, I can sign up for the site, so that I’m able to have a personalized experience. As Tom, I want to only see updates from close friends, so that I can view relevant updates during my time online.

As wh o, I want what, so that why.

Who?

Another Template
Some stories benefit from more than one “who”. In those cases, you might want to include multiple who-why pairs. what: Track history of which products registered shoppers have viewed. who: Registered Shoppers why: So I can go back and find again (and buy) what I’ve previously researched who: Marketing why: So we can serve ads that are relevant to the interests of individual registered shoppers.

What?
The “what” in a user story specifies the need, feature, or functionality that is desired by the “who”. This is what the team will build into the software or service.

Why?
The “why” in a user story specifies the value, keeping the needs of users and customers front and center. Agile’s focus is on valuebased delivery, so it is extremely important to understand why the story should be delivered. If you can’t write a user story with the “why” included, then maybe it’s not needed.

USeR SToRieS GUide (ConTinUed)
Getting Started A simple statement in user story format gets us started, but the delivery team still needs more information. That’s why we use the Three C’s: Card, Conversation and Confirmation, to provide additional context. Card The card is a place to write the “who”, “what” and “why” of a user story. An index card is small and mobile; it represents a small space to tell a succinct story that is easy to move around during backlog prioritization. The card captures the general idea and is the promise for a conversation. Common questions might include: What type of authentication do we need? What information do we need to collect about the user? Are there different types of users that we have to worry about? The whole team can participate in these discussions. Different roles and different viewpoints will surface different questions and concerns. Confirmation A well-defined user story is testable. As part of the conversation, the Product Owner and the Delivery Team work together to write acceptance criteria, “confirmation” that the story is completed satisfactorily. High-level acceptance criteria statements are usually sufficient. Conversation The card provides the basis for a conversation between the Product Owner and the Delivery Team, in which they develop a sharing understanding of the functionality goals and any constraints. The Delivery Team asks questions in order to understand the underlying context and intent. The Product Owner answers the questions, using this input to drive a shared understanding of what will be delivered, removing any ambiguity. Common acceptance criteria might include: Username, password, and email address are all required. Display name can be provided, but is optional. Passwords can be 6 – 200 characters in length. Passwords should be stored encrypted and cannot be decrypted.