Agile development culture advocates giving importance to individuals over processes and tools, and user stories lend a human aspect to the feature backlog. A user story isn't just about what you're building—it should also help you understand why you're building it. This understanding will also improve The process of how you build the same feature.

A typical user story might look like this:
"As a <user role>, I want to <feature> so that I can <receive benefit>." "I'm Brad, a user of the online flight booking portal, and I want to know if my ticket is booked so I don't have to try booking again."

Knowing that you're helping a human solve a tangible problem with the feature you're building is more motivating than just developing a list of features your manager assigned to you. Good user stories don't just help with customer satisfaction—they also help improve employee-customer relationships.

Good user stories don't just help with customer satisfaction, they also help improve employee-customer relationships.

User stories help you define how your user will perceive and engage with each feature.

Why write user stories?

User stories help you find clarity. For example, if your task is to create a "Login page," you might simply visualize a screen where the user enters their username and password to access the platform or service. However, when you imagine a human in front of the login page, you might realize you'll need an error message if the credentials are wrong and a password recovery mechanism in case they forget their password. User stories help you define how your user will perceive and engage with each feature.

What are they made of?

A user story usually has three components:

Title:

The title should be concise and explicit. Something like "Add signup form on the homepage" is a good example while "Make agreed upon changes" is not.

Description:

The description is the heart of the user story, and is often written using a template. For example, "As a customer of an online cab booking service, I want an online payment to be an option so I don't have to carry cash with me all the time." 

Acceptance Criteria:

This is used to define when a user story can be deemed complete. Writing good acceptance criteria is an effective way of exploring all the details of a user story and 

For example, let's look at this user story:

As a university studentI want to know my fee for the semesterso that I can pay the amount.

Acceptance Criteria for this story may be:

1. The fee is displayed.2. The fee is calculated.3. The fee for the upcoming semester is displayed.4. The fee is not displayed for an invalid student ID.

Acceptance criteria are defined before development begins. A good practice is to write them in clear, simple language, which can be translated into manual or automated test cases.

How to write user stories?

A user story is the smallest chunk of a product feature that you can explain independently. It shouldn't contain technical details, should be captured in a sentence or two, and should prompt a discussion during which the details are nailed down.

User stories should be written in plain English without technical jargon so non-technical members of the team to contribute to the discussion. Developers work with many technologies and often use acronyms and jargon that might not be understood, even within the same team. With user stories, anyone can contribute by simply putting themselves in the shoes of a potential user.

The Product owner who has a clear vision for the product along with a sound understanding of its user base—should write the first set of user stories. As the team starts brainstorming, all stakeholders can contribute user stories, including the development team.

With user stories, anyone can contribute by simply putting themselves in the shoes of a potential user. 

User story templates and formulas

There are helpful templates which can be used for writing user stories. Some examples of these templates are:

INVEST
  • I

    Independent

    The goal a user story aims to achieve should be independent of other product goals.

  • N

    Negotiable

    The details of a user story should be up for negotiation. For example, the first iteration of a login page can go live with just an error message. A password recovery mechanism can be added later. 

  • V

    Valuable

    A good user story should add value to the end user.

  • E

    Estimable

    It should be possible to estimate the efforts required to complete a user story.

  • S

    Small

    The goal defined should be small enough to fit within one sprint.

  • T

    Testable

    Any feature or enhancement that is the result of a user story should be testable - you should be able to write acceptance criteria before it's implemented.

Role-feature-benefit

This is the most popular template used. It looks like this:  As a <user role>, I want to <feature> so that I can <receive benefit>. Some teams go a step further and use an actual name to make their user feel more human. 

Card, Conversation, Confirmation

The 3 Cs formula captures the components of a user story.

Card:

Typically a sticky note with a rough one- or two-line description of the user story

Conversation:

A largely verbal conversation about the user story and how it can be explored. This could include anyone remotely involved with the feature

Confirmation:

A tangible output which confirms the conversation's objectives have been achieved. 

Given-When-Then

Given (some context or description of the situation) When (some event(s) occur ) Then (some observable reactions should occur)

It's not unusual for teams to fall into the rote application of these templates. A template or formula can be a useful reminder to keep the conversation focused on the user. Remember, normal phrasing can be just as effective in communicating the essence of a user story—the discussion around the user story contributes more to its implementation than the initial two lines written on the card.