User stories: a beginner’s guide

A user story is a short description of something your customer will do on your website or application, focused on the value they get from the process. Get an introduction to user stories — what they are, how to write them, why and when to use them — and find out where to get additional resources.

One of the things I love about user stories is that they’re great for people who aren’t used to commissioning websites or applications. If you haven’t needed to communicate requirements before, user stories are a good way to start.

I had a chat recently with a group of staff from one of our clients. They wanted to add a new chunk of content to their website. They had tried to use an existing template but it wasn’t a good fit. The way they needed to present this content was quite different from anything they’d tackled so far.

I suggested that user stories would be a really good way to define and record what the group wanted. I thought they would form a good basis for scoping the work required to deliver new functionality. This post is effectively a record of our conversation.

What is a user story?

A user story is a short description of something that your customer will do when they come to your website or use your application/software, focused on the value or result they get from doing this thing.

The user story is:

written from the point of view of a person using your website or application

written in the language that your customers would use.

How do I write one?

The basic technique is simple. Take this format: An an [actor] I want [action] so that [achievement].

… and fill it out. For example: As a Flickr member I want to be able to assign different privacy levels to my photos so I can control who I share which photos with.

The actor makes sure you’re thinking about who will use this feature. If there isn’t an identifiable customer for the feature, you should reconsider whether you need it.

The action describes what will happen, but not *how* it will happen (so in the case above, not ‘I want to pick an option from a list of three possibilities, using a radio button display’). User stories are designed to start a conversation within the team about the best way to make this feature.

The achievement describes the ultimate purpose of the feature. If you can’t think of an achievement, that’s a signal that you should reconsider whether the feature you’re trying to describe is actually important.

And that’s the heart of the matter. For a little more detail, check out this post by Mike Cohn on the ‘user story template‘. In a later post I’ll cover the INVEST model, the acceptance criteria that get attached to user stories and how they get used in the development process.

When do you use them?

User stories are at the core of the Agile project management methodology. However, I believe they are the most useful way of documenting what your website or application needs to do for users, regardless of how you’re running your project.

You should write your stories at the beginning of your project, before you start making any decisions about technical solutions or design. Once you’ve written the stories, prioritise them from most important to your customer to least important. One of the beauties of Agile is that you can keep writing and reprioritising your user stories throughout the development period.

They are an alternative (or possibly a complement) to requirements documents and use cases. These two blog posts give good overviews of the advantages and drawbacks of these different techniques for documenting what a website or application needs to do:

Why use them?

make you think about what you’re building from the end-user’s perspective

lend themselves to prioritisation

can be added to, modified or deleted throughout the development process

capture discrete actions/functionality

can help with planning people’s work

reduce upfront planning time: you only get stuck into the details when you start working on that story.

Some drawbacks:

they can be tricky to write for backend or process tasks

they don’t look like a requirements document, and therefore it can sometimes be hard to convince people (often ‘management’) that you’re “following process”.

From my perspective — as someone who’s recently moved over from the client/Product Owner role — the biggest advantage is that they don’t make you think about how something will be implemented; instead they focus on the who and the why. This lets clients/commissioners/Product Owners bring their expertise to bear on defining the who and the why, and lets designers and developers bring their expertise to bear on the how.

In this way, user stories create a common ground where everyone involved can meet to have a conversation — as I said at the start of this post: communication and user stories.