How to write a user story

By Simon Buehring 

Writing user stories takes a bit of practice when you are new to agile. That’s why we have developed this simple guide and handy graphic to get you started! They are covered in the popular Agile Project Management course.

If you think this guide will give others a good start to writing user stories, feel free to link to it from your blog or share it with your networks.

What is a user story in agile?

A user story is a simple description of a requirement and is a popular agile method to capture user requirements. It serves as a guide for the team about a user requirement. User stories are one of the many agile technique or methods which you will learn on the Agile Project Management courses.

User stories provide context and clarity of expectations, without focusing on technical details. Defining technical details too early can discourage alternative design options and changes. Being purposely vague, user stories provide room for creativity and interpretation.

A user story speaks from the end user perspective and follows this format:

As a ….. I want to ….. so that …..

User stories encourage team conversation which may uncover hidden assumptions and requirements. They are to be kept brief and should always meet the allocated acceptance criteria or definition of “Done”.

Who can write a user story?

Users are the ideal people to write user stories. If you’re using Scrum, it’s the Product Owner’s job to keep the Product Backlog full of user stories. The highest priority stories are pulled from the backlog to work on during a Scrum sprint.

How to write a user story

The key to writing an effective user story is to determine the who, what and why. Ensure that your user stories follow the I.N.V.E.S.T. standard – independent, negotiable, valuable estimable, small and testable.

1. Define your end user

The first thing to do when writing your story is to define your end user. Who is the person that will be using your product? A helpful way to visualise your user is to make them a persona profile. Give the person a name and find them a photo. Add their relevant attributes, attitudes and behaviours. Finally, give them a goal. The following example is a user definition for a smart baby monitor.

Example:

As a [parent]

2. Specify what your end user wants

For this part you’ll need to think about the solution your product is offering. What does your end user want from your product? Refer to the “goal” section of your persona profile, then add a brief description of this to your story. The following example shows what the end user wants from using a smart baby monitor.

Example:

As a [parent], I want to [check up on my sleeping baby without going into their room]

3. Describe the benefit of your product

Imagine that you are the end user speaking to the product developer. Tell the developer the benefit you will gain from using this product. The following example shows how the end user will benefit from using a smart baby monitor.

Example:

As a [parent], I want to [check up on my sleeping baby without going into their room], so I can [ensure their safety without disturbing them].

4. Add acceptance criteria

In agile, teams are required to deliver products that are potentially shippable. Acceptance criteria is the clearest and quickest way to determine whether a user story is done or not-done.

Each user story should have at least one acceptance criteria but try not to list too many. You can use S.M.A.R.T objectives to ensure your criteria are measurable. Always remember to write from your end user’s perspective and not confuse acceptance criteria with a to-do list.

Example:

As a [parent], I want to [check up on my sleeping baby without going into their room], so I can [ensure their safety without disturbing them].

- Night camera installed on baby’s cot monitor
- Baby temperature and breathing monitor function
- Data sent to parent’s smartphone
- Parent alert sent to smartphone if problem occurs

Start building your backlog

Once you have written your user story, you can add it to the backlog. Once you have a bunch of user stories, you can work on prioritizing and estimating the effort.

Embracing change is all part of the agile ethos, so product requirements may change during a sprint and you can refine your user stories as you progress. If you find that your user story is becoming complicated or undoable, you can break it into smaller user stories. That way, the stories are less likely to be left not-done at the end of a sprint.