What is a User Story and How do You Write One?

User stories are simple and rewarding tools for software development that focus on meeting users’ needs while providing the greatest business value. They provide an alternative to traditional software development planning with detailed requirements by prompting consistent and efficient communication. Learning to write good user stories can help your team maintain transparency with product owners throughout the development process and provide the greatest value to end-users. 

What is a user story?

A user story is the expression of a user’s need expanded through conversations between stakeholders using an Agile approach to software development. The story begins with a written description of a user, his or her desires, and an end goal or benefit. A user story is initially written in 1-2 sentences on an index card or Post-It note. It follows the format: 

As a [specific user], I want [need] so that [benefit/reward].

User story examples:

• As a student, I want my profile to list my courses and include a link to each course homepage so that I can access daily assignments.
• As a site visitor, I want to read a new article on the homepage daily so that I am up-to-date on the latest events.
• As a site visitor, I want to read the privacy policy so that I know what information will remain private. 

A good user story is simple and concise. Using technical language creates a barrier between the team and the product owner, and excessive details leave nothing to discuss. The story should be a prompt for discussion rather than a document of detailed criteria. Ron Jeffries describes the process using 3 C’s: card, conversation, and confirmation. Within an Agile framework, like Scrum, user stories are developed during iterations or sprints and refined by implementing feedback from the conversation.

What should a user story include?

A user story should include the user [who], his or her need [what], and the end goal [why]. The format is simple, but certain qualities distinguish good user stories from bad ones. Bill Wake uses the acronym INVEST in Extreme Programming Explored, to explain the characteristics of a well-written user story. 

• Independent. One user story should not depend on another for completion.
• Negotiable. A story is a brief conversation prompt and not so detailed that nothing remains open for discussion.
• Valuable. A story is structured to feature the value particular software will provide to its users
• Estimable. A story’s time to completion should be measurable based on its complexity and assigned within an iteration.  
• Small. A story should be manageable enough to be completed within a few days.
• Testable. Successful completion of a story can be measured by pre-determined acceptance tests.

How to write user stories

1. Learn about your users. First, figure out the scope and target of your users to avoid developing user stories for every single type of user. Perhaps anyone will want to use your website or app. Perhaps only people within a certain vicinity will benefit from its features. The best way to create accurate user stories is to converse with potential users and receive their feedback during the development process. 
2. Define your users. Scribbling a name on the card will not suffice. A name does not provide any information about the user. Instead, give a title (site manager) or a brief description (new user). You don’t need to note that your user loves soccer, lives in Cleveland, only uses the app on Saturdays, and loves Lay’s potato chips, but you may want to. Creating a user persona can be exciting and give you insight into the desires of your users. User personas include the name, description, and goals of a user.
3. Write story descriptions. Keep them short (1-2 sentences) and informal. You may want to start with larger, epic stories and break them down into smaller segments during the planning process. Don’t use technical jargon that does not match the persona of the user and is not easily understood by people outside of the development team. 
4. Converse with team members and product owners. Details are revealed during discussion and should not be scrutinized during iteration planning. 
5. Refine the story card. All good stories go through revision. User stories are fluid, not contractual, and implementing feedback is crucial to their completion. 
6. Add acceptance tests to the story card. Acceptance tests guarantee that the story meets a user’s needs, as well as any detailed criteria from the development team. 

Creating Agile user stories

User stories go through different phases of development within an agile framework: 

1. Writing  
2. Product backlog  
3. Iteration planning  
4. Development  
5. Testing 
6. Confirmation

Who writes the user story? 

The customer team or the product owner write the user stories. Developers do not usually write the stories but do collaborate in the planning process. They estimate how long each story will take to complete, assign each story a certain number of points based on complexity, and then determine how many story points can be completed per iteration. 

When should you write user stories? 

User stories can be written at any point during the project and added to the product backlog. Stories are prioritized by greatest user and business value. They are selected from the backlog and sorted into piles based on priority. One pile contains an average of 10 stories to be completed per 1-2 week sprint. A user story should not span multiple sprints. Instead, it should be split into smaller stories or saved in the backlog. Conversations including the customer team, developers, and product owner should take place during iteration or sprint planning and after each 3-6 month release.

How do you add details to a user story? 

Acceptance tests prove that all the details have been successfully taken care of and ensure the completion of a user story. If a story is too broad, it could be split into smaller ones. Details are added during conversations once work on a project has begun, not during the story writing stage.

Types of user stories

1. Epic: A larger, broader user story intended to be split into smaller stories before development. An epic may be written in the user story format or as a simple phrase.

Example: User profile

2. Functional: High-level stories describing a function that brings direct value to the end-user. This type of story follows the standard user, need, benefit format.

Example: As a site member, I want my profile to display my work experience so that I can attract potential employers.

3. Technical: Optional sub-stories that support a functional user story for additional clarity and organization. Technical user stories are written by developers or others who understand the technical ramifications. These stories are written for the benefit of the development team and not presented to the product owner. They could be used for bug fixing, refactoring, and developing infrastructure. 

Example: In order to build the user profile, we must allow a user to sync with their LinkedIn account via a LinkedIn Social Sign-In button, to pull their work history directly into the database.

User stories vs use case

User stories and use cases are similar but written with different goals in mind. A use case prioritizes text, while the user story prioritizes conversation. A use case focuses on technicalities at the outset and provides less room for discussion throughout the development process. It provides a more permanent document including an expanded scenario and extended details. 

User stories vs requirements: Requirements are written, but user stories are discussed. Requirement documents resemble “to-do” lists, but stories act as a source for requirements. 

User stories vs tasks: A task is an item of work that can be accomplished independently. User stories are never meant to be completed as a solo project. Collaboration and conversation guarantee a successful user story. 

Benefits of good user stories

• Ensures your team consistently delivers features that bring direct value to the user
• Prevents wasted time developing an overwhelming number of features at the beginning of a project without accounting for a bad user experience and decreases user attrition
• Eliminates detailed, contractual agreements at the start of a project that limit creativity and prevent decisions based on experience
• Allows the product owner to be involved in the development process
• Enables creative problem-solving
• Helps build a strong relationship with product owners through transparency and consistent communication
• Allows for adjustments throughout the project

User stories for mobile apps

Creating app user stories provokes feedback and discussion around what your app is doing successfully, what users want from your app, and what your app is lacking in regards to engagement and experience. When writing a user story for your mobile app, be careful not to assume every user is going to want a particular feature. If your app has too many functions, you may need to return to the drawing board to work on the most essential features that provide the greatest value to the user. 

To ensure that you create an app user story best suited to a user’s needs, ask:

• Who is using the app?
• Who is unlikely to use the app?
• What are their desires, needs, and expectations?
• What does this app offer that your website can’t, or that the competition can’t?
• How will we ensure proper feedback and metrics to track this information?

Examples of user stories for app development

• As a typical user, I want easy navigation since there is so much to do on the app.
• As a rare user, I want re-immersion engagement so that I can get reacquainted easily with how the app works.
• As a skeptical user, I want to easily control my privacy settings and know what security protocols are used so I can feel safe.

Make sure you apply feedback from real users based on actual app usage and experience. Don’t always assume your team knows everything about your end-user. Their desires, behaviors, and preferences vary. And don’t rely solely on user stories in app development. Utilizing other methods, like segment analytics, customer mapping, and tracking user flows, helps gain a better understanding of user behavior.

Why write user stories?

A well-developed app or other software should improve the lives of users in some way or provide a reward based on their usage. User stories help your team strike a balance between app experience and app reward and help ensure that features meet and exceed user expectations. If the reward for using a feature is great but the experience is overwhelming, or if the experience is fun but the pay-off is underwhelming, a user is not likely to return. User stories allow for constant review and modifications throughout the development process, and team members begin projects knowing the value each feature will provide.