User Story

What is a user story?

User stories are either written by a product manager or a team member on behalf of the end-user, explaining the expected functionality from the system being developed. User stories are written to capture the most important elements of a requirement following a predefined template. The most commonly used user story template is called the connextra template where a user describes his role, his capabilities, and what benefits he expects to receive from the system using a single sentence.

Users should keep the following agile principles in mind when writing user stories.

1. Working software is the primary measure of progress.

2. The highest priority is to satisfy the customer through early and continuous delivery of valuable software.

3. Simplicity.

High-quality user stories not only help project teams to clearly and precisely understand customer requirements but also make the project estimation and development process more efficient.

eBook

Leveraging
Product Strategy

Read now

What are user stories used for?

User stories are used as the primary way to capture high-level requirements in an agile development framework such as scrum and eXtreme programming (XP).

In the agile scrum framework, items in the product backlog are written as user stories because it helps the project teams and product owners to focus on the requirements from the perspective of the customer.

In eXtreme Programming (XP), user stories are used as criteria for product acceptance. The XP developers make use of the user stories to write acceptance tests that are done even before the product code is created. This approach saves time and ensures that the project code meets the client's acceptance criteria. User stories are also used in creating the estimates for release planning meetings in the XP framework.

History of user stories

The initial idea of the user story was generated by Dr. Alistair Cockburn in the late 90s. The way user stories are used has been developed by multiple practitioners since then, namely:

• In 2001, the "Three C's" formula for user stories was proposed by Ron Jeffrey. The three C's stand for card, conservation, and confirmation.

• In 2004, Mike Cohn published the book, User Stories Applied For Agile Software Development generalizing the user story principles.

• In 2014, Jeff Patton and Peter Economy published the book User Story Mapping: Discover the Whole Story, Build the Right Product to introduce a new set of techniques to identify, structure and provide more visibility to user stories.

Examples of user stories

User story templates are created to identify who the end-user is, what the end-user wants and why they want it in a single sentence. 

Download now: Get our 5-minute guide on How To Use the Story Mapping Method

These are some examples of user stories written using different templates that are adopted by agile development teams to capture their requirements.

1. The connextra template introduced by Rachel Davies

Template : As a <role> I can <capability>, so that <receive benefit>

Example: As a manager, I want to be able to view the status of ongoing work, so that I can plan when to deliver it to senior leadership.

2. The user story template revised by Chris Matts

Template : In order to <receive benefit> as a <role>, I can <goal/desire>

Example: To add new friends to my profile as a user, I should be able to send friend requests to other users.

3. The user story template revised by Elias Weldemichae

Template : As a <role>, I can <goal/desire>, so that <why>

Example: As a follower, I want to be able to comment on the blog, so that I receive feedback from the author.

4. The user story template based on the five W's model

Template : As <who> <when> <where>, I <want> because <why>

Example: As a software tester when I log a defect under each developer's name, I want each of them to receive a notification because then the developer will then be aware of the defects I logged.

Advantages of using user stories

A well-formed user story can benefit the software development process in the following ways:

• It helps to articulate precise user requirements: User stories are only successful if they include key elements such as a user's role, capabilities, desires, and goals in a single sentence. Having these elements clearly articulated makes them much more precise to the entire product team, ensuring that development stays laser-focused on end-user needs.

• Better collaboration: User stories help to align all key stakeholders on not just what is being developed, but why.  

• Being able to reduce project risks: User stories are, at their very core, a user-centric tool for the product team. This helps to make sure that oversights and scope creep are caught early on.

Disadvantages of using user stories

These are some of the issues that agile development teams have faced when using user stories to capture requirements.

• Less focus on non-functional requirements: User stories mainly focus on capturing functional requirements (i.e. how end-users directly interact with the system). The non-functional requirements such as performance, fault tolerance, usability, durability, modifiability, etc. may not be captured clearly or at all through the typical user story templates.

• Difficult to scale for larger and more complex projects: The format of user stories is simple formats that focus on a single functionality. These can sometimes be difficult to scale up as a project becomes more complex.

• Produce vague or incomplete requirements: As user stories are written in an informal and more natural language, the requirements may be too vague for engineers to work with. This can, however, be overcome with proper training in how to write great user stories.

How to write a user story: step by step

User stories need to place the user at the very core of the conversation. Product teams need to capture functionality from their perspective in order to identify ways to offer real value. To help you and your team fully understand what, who and why you’re building a product, user stories need to be short and to the point. 

If you’re wondering how to write user stories, just follow the four steps below.

Step 1: “Who?”

There is a tendency to simply refer to users as “the user”. They use, or will hopefully use, your product, so we’ll just call them “the user” for ease, right?

But this can be problematic, as it can be applied to anyone and risks overlooking the unique needs of your target and what their pain points are. To help frame the opportunity more clearly, it’s better to get a little more specific when discussing user needs. 

You want to keep your target audience in mind during these conversations, rather than just thinking about a generic person trying to use the product. So rather than just saying “user”, try creating a buyer persona that encompasses key traits your target audience will have. 

Step 2: “What?”

Now we have established who we are building for, it’s time to look at the functionality they expect to see and how they will interact with the product. 

It’s important to keep in mind that user stories focus on one single action. So if your user is looking for the ability to browse items and add them to the cart, that would be two separate user stories: 

• In order to choose an item as a customer, I can view a catalog of items.

• In order to buy an item as a customer, I can add my selected item to the cart

To help teams build features that add real value, they should avoid focusing purely on features a user wants. Instead, they should focus on the intention behind the feature. 

Say you’re working on a social media site, rather than writing a single user story for managing user profiles, it’s better to split that into each action that profile management may involve. For example, “I want to upload my profile photo” or “I want to link my payment information to my profile”.

Step 3: “Why?”

With the who and the what all figured out, it’s time to look at why we’re building the product.

Each user story should contribute something towards the product goal. At the same time, we need to identify what value the user will receive from performing the action that the user story focuses on. 

If you cannot answer that question based on steps 1 and 2, you need to go back to the start and rethink the user story. 

Step 4: Discuss

Now you have answered the three questions, open up the floor for a group discussion about the user stories you have created. Any issues should be addressed and whoever writes the user story has an opportunity to clarify something if required. 

Now that you know how to write a user story, all that’s left to do is start!

eBook

Leveraging
Product Strategy

Read now