What is a user story and why should you be writing them?
The phrase ‘user story’ is misleading. It creates an image in your mind of a long, opinionated piece of writing – the kind of article that a software reviewer might post sharing their experiences with a new product or app.
This couldn’t be further from reality. So, what is a user story, how do you write them, and is it worth you even bothering? (Hint: yes, it really, really is.)
What is a user story?
A user story is a software development tool. Its purpose is to generate understanding of a software feature from the end user’s perspective. In one sentence, a user story will describe user type, what that user wants, and why.
You may have more than one type of user for any given software product. User stories look at a product’s features from each different end-user’s requirements, to represent the needs and wants of a full client base, rather than a single individual.
How to format a user story
User stories are usually written on index cards or even sticky notes, meaning that they are short and sweet. The general structure of a user story is ‘As an [end user role], I want [ability or feature of the product] because [the benefit/function of the feature].’
That doesn’t leave much room for detail, but that’s kind of the point. Instead of wading through details and demands, user stories provide a quick, concise way to capture the desired functions of your software product.
Don’t get lost in the details
There are two ways to add extra detail to user stories. The first method involves breaking down your main user story into multiple, bitesize user stories. Often, the main user story for your product will encompass a wide area of functionality, known as an epic user story. Epic user stories can then be divided into smaller key functions, meaning that each user story details just one function that your product will perform to fulfil the epic user story you started with.
Another way to add detail to your epic user story is to supply acceptance criteria. These are criteria that must be met by the final piece of software to meet the epic user story, and define the boundaries and parameters that determine when a story is completed and working as expected.
Real-life examples
The best way to answer, “What is a user story?” is to give practical examples. For our live chat software, we create user stories and acceptance criteria for both the website visitors clicking to chat, and the agents on the other end who are chatting back. We also break down these stories based on each point in the journey: from the moment a visitor lands on a site or the moment an agent logs in to the software.
For an agent logging in, this can be as simple as:
Login
As a customer, I expect to be able to login using my personal details so I can use the product.
Acceptance criteria
It’s done when a user enters his/her correct details into the client and the client login to show the main window.
For a website visitor, it’s similarly straightforward:
Starting a chat
As a visitor, I expect to have the ability to start a chat so I can enquire about a product/service.
Acceptance criteria
– It’s done when I come to the site I can see a chat button.
– It’s done when I click on the chat button, a chat begins and I am put in the queue waiting for an operator.
These are two of the more basic examples of user stories and acceptance criteria, but they give you a feel for the pragmatic approach you need to take.
Benefits of writing a user story
So, now we’ve answered, “What is a user story?”, let’s explore why you should be writing them. In the first instance, user stories open discussion. They provide the end goal and why, without restrictions on how to reach these goals. As such they open opportunity for your development team to be creative in finding solutions to fulfil the user story.
Creating a user story also aids cross-department communication and understanding. Because they highlight what needs to be completed, aspects of development relevant to other teams such as time and budget estimation have a starting point to be discussed. They provide a visual understanding of how much needs to be done before a product is ready for release. This, in turn, improves the planning process during development.
Streamlining
Supplying a user story will streamline your product goals. By breaking that into smaller, bitesize user stories and acceptance criteria, you create obtainable sub goals for your development team.
Also, a user story will help to avoid feature creep in your software. They keep the main product functions clear and highlight what the end user actually wants, rather than what your teams think they need. These sub goals mean that the product development and final solution is organised and tidy, instead of a confused mess of features.
Team motivation
So, user stories help improve your development team’s motivation by making the product easier for them to complete – keeping the clarity and structure of the small, doable tasks.
Plus, because a user story will give a reason why a feature is desireable, it can also give your developers a sense of purpose in their work. It is often easier to complete a task when you know why you are doing it and what value it adds overall.
Happy customers
A user story, when it comes right down to it, will mean happy customers. The control over product features that a user story enables is essential in creating a great user experience. That’s not to mention the benefits to team organisation.
So, what is a user story? If you want a quality software product, it’s what you need to start with.
