fShare
0
Pin It

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! 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 provide context and clarity of expectations, without focussing 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]

Courses picked for you

AgilePM Foundation

Gain an understanding of agile methods in just 3 days

AgilePM Foundation & Practitioner

Understand agile and get full certification in just 4 days

Professional Scrum Master

Learn how to become a Scrum Master in 3 days

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.

Courses picked for you

AgilePM Foundation

Gain an understanding of agile methods in just 3 days

View PRINCE2 courses

AgilePM Foundation

Gain an understanding of agile methods in just 3 days

AgilePM Foundation & Practitioner

Understand agile and get full certification in just 4 days

View PRINCE2 courses

AgilePM Foundation & Practitioner

Understand agile and get full certification in just 4 days

PRINCE2 Agile Practitioner

Learn how to use PRINCE2 with agile in 3 days

View IPM courses

Professional Scrum Master

Learn how to be a Scrum Master in 3 days

fShare
0
Pin It

Simon Buehring

Simon Buehring is the Founder and Managing Director of Knowledge Train.

View Simon's Google+ profile

Recommended posts for you

All about agile: What is it and what makes it different?

Agile is from mars and project management is from venus. But can project management be agile?

Manifesto for Agile Software Development: An illustrated guide

Learn the four key values in the Manifesto for Agile Software Development.

Top 15 books about agile you must have on your bookshelf!

Here are the top 15 agile books that are worth reading.