My two favourite things about Agile development:
- Communication
- User stories.
One of the things I love about user stories (don’t worry, I’ll get to a definition soon) is that they’re a great technique to help people who aren’t used to commissioning websites or applications communicate their requirements.
I had a chat recently with a group of staff from one of our clients who were looking to add a new chunk of content to their website. They’d had a go at using an existing template, and discovered that the way they needed to present this content was quite different from anything they’d tackled so far. In addition they’d been having conversations with some of their customers, who introduced new ideas for how the content could be used.
I suggested that user stories would be a really good way to define and record what the group wanted, and 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.
User stories are:
- 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. You 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 user stories 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.
User stories should be written at the beginning of your project, before you start making any decisions about technical solutions or design. Once they’re written they should be prioritised, 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.
User stories are an alternative (or possibly a complement) to requirements documents and use cases. These 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
Why use user stories?
Commonly cited benefits of user stories include:
- they make you think about what you’re building from the end-user’s perspective
- they lend themselves to prioritisation
- they can be added to, modified or deleted throughout the development process
- they capture discrete actions/functionality
- they can be used in planning people’s work
- they 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 user stories 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.
Coming soon
Keep an eye on the Boost blog for follow-up posts on the INVEST model, acceptance criteria, and bringing stakeholders onboard with Agile.
Thanks for the information and I really appreciate you including the “clip this” for evernote because thats what I did about halfway through.
Thanks a lot – glad you enjoyed the post, and the clip this functionality as well. Good to know people are using it. Thanks for the comment.
project management…
[...]User stories: A beginner’s guide[...]…