By Nathan Donaldson
Tags: Agile
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.
My two favourite things about Agile development are: 1. communication and 2. user stories. With that in mind, we’ve put together an introductory series on user stories.
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.
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:
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.
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:
Advantages of user stories for requirements – Mike Cohn
Requirements 101: User stories vs use cases – Andrew Stellman
User stories:
Some drawbacks:
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.
Product Owner’s guide to user stories in Scrum
Starting a new project? Check out our Agile Project Kick-off Kit to learn about user story mapping and prioritising user stories during project discovery.
