Getting started with user stories

Think about the last time you bought something at a shop or online: Did you care what brand of vehicle delivered the goods? Probably not!

In the Cornwall Council IS team, our products exist to help people get things done and they, in turn, are helping other people get on with their lives. Often, as long as these people can do what they need, the details of how our products work do not matter very much to them.

User stories are a way of capturing the needs of our users and leaving out the rest of the details. They are very efficient, easy-to-use and have become the typical way for agile teams to define their products in the product backlog.

About agile in Cornwall Council

We are starting to adopt more agile ways of working. My role involves helping people develop their skills and apply agile techniques to improve the services we provide to the public. This series of posts is adapted from the articles I write for our internal teams. They cover some common agile terms and what it all really means.

Getting to the heart of users needs

Most of our teams have seen the default format for a user story by now^[1]:

As a <type of person, role, group> I want <something> so that <some outcome>

The something is a part (potentially a tiny part) of our product. The sum total of these stories, and there could be thousands of them, defines our product. The collection of people, roles and groups define who we are intending to help, while the collection of outcomes captures what those people are trying to achieve.

This seems very simple but, as skilled professionals, do we need anything else to do our work?

Working with your user stories

As well as collecting stories in your product backlog^[2] you can:

• Break them down into smaller sub-stories to help plan delivery
• Sort them into larger groups (often called features, epics or themes) to help manage priorities
• Annotate them with additional details (acceptance criteria are a common annotation)

Writing user stories gets quicker and easier with practice, and the stories in your backlog will get better through discussion amongst the team and your users^[3]. If you find it difficult at first, don’t worry. You are not alone! To get started, just have a go and write something down and you can revisit and update your stories in later sprints^[4].

Team Bumblebee^[5] is going through this learning process at the moment, and it will be obvious if you have a look at the stories in our backlog. Some of the items have come from creative team-working sessions and still need to be refined into user story format. Some of our stories are a little self-centred (written as if the team members are the users) so we need to keep working on how these items will help others and capture that more clearly. We’ll get better at it as we go.

When the going gets tough

Sometimes, you’ll know you need to get something into your backlog but just can’t find an easy way to get it into a user story format. That’s ok! Capture the idea so it doesn’t get lost and revisit it later. You might also want to ask the following questions:

• Who else wants the thing you have written? If it is just you, should we really spend time on it?
• Why do they want it? If there is no value, should we drop it?

If you can find the what, who and the why you probably have enough for a user story. If not, you probably shouldn’t be working on it.

An exercise

At the start, we talked about shopping and not caring about how your goods arrived. Perhaps you would care if they arrived in a poorly maintained, highly polluting, old diesel van. Can you capture that in a user story? Go on, have a go!

Footnotes