How to write a user story — a beginners guide
By: Neha Nathani
Tags: User Stories, Software Development, Scrum, Product Management, Agile

Before learning how to write a user story, it's important to understand what exactly a user story is and its purpose.

A user story is a high-level description of a feature told from the perspective of the user. It is the smallest piece of work that can provide value to the user and can be delivered in a single sprint.

The purpose of a user story is to articulate how a piece of work will deliver value back to the user. Note that the “user” doesn’t have to be an end-user in the traditional sense, the user can be anyone who gains value from the feature being built. For example, if a product manager wanted to learn more about their users through a data collection feature, then the user for this story would be the product manager.

How to write a user story?

A user story is often written as an equation:

As a <type of user>, I want to <desired feature> so that I can <value gained>.

A further breakdown of each component;

Type of user: this is the ‘who’, who are you building this feature for? Who will benefit from this user story? Remember, it's common to assume all features are built for the end-user but features can be built for anyone who benefits from the feature being built.

Desired feature: this is the ‘what’, what are we building? What is the intention of this feature? What will it accomplish for the user?

Value gained: this is the ‘why’, why are we building it? What value or benefit does this feature provide to the end-user? This can also be looked at as what problem does this feature solve?

Example user stories:

Food delivery app: As a frequent food orderer, I want to be able to invite my friends, so that I can get referral incentives

Mobile banking app: As an app user, I want to transfer money, so that I can quickly send money without using a computer or going into a bank

Rideshare app: As a passenger, I want to rate my driver, so that I can share my feedback

Other helpful information to provide when writing a user story

Besides the user story itself, there is additional information that should be shared with the developer, usually in some form of a ‘ticket’. This information will include additional context for the team/developer to ensure the feature is built right the first time. Some examples are:

Link(s) to designs — designers often use Figma, Invision, or Zeplin to share designs with developers. Link to product requirements —this will be a detailed document provided to the developer and includes feature functionality, user experience, scope, risks, and more. Technical requirements—they typically refer to how the software should be built and any considers that a developer should take into account when developing the feature. Acceptance criteria — a checklist to confirm that the work completed meets the intended purpose and functions as expected before being marked as ‘done’.

Conclusion

Just like any form of writing, writing user stories is a craft of its own. It takes time and practice to nail it down. It’s also important to remember that every team is different, what works for one team, might not work for the other, so there is definitely some trial and error. If you’re looking to improve your user story writing, always ask your team for feedback. You’ll quickly learn what is working and what isn’t.