How to write meaningful User Stories
I’ve seen a lot of projects fail when by all accounts, they shouldn’t have. The reason for this nearly every time, was that the requirements gathering stage of a project was done poorly, or sometimes not at all. Sometimes this is driven by budget or deadline constraints, and sometimes it’s because the people responsible are just unaware of how to go about gathering requirements in a structured manner, and if you’re one of those people, or know one of those people, then please read on.
Requirements exist to make sure that what you think you are building, is the same as what the client or stakeholder thinks you are building.
Requirements serve many purposes, but when you strip them down to their core, requirements exist to make sure that what you think you are building, is the same as what the client or stakeholder thinks you are building. Because of this, they should be as easy to read and understand as possible, which things like functional specification documents usually aren’t.
There are many types of people that think many different ways. Designers are usually visual thinkers, and Developers are usually logical thinkers. Clients could be either. To help as many different types of people understand your documents, I recommend using at least 2 different techniques to form your final document:
- User Stories
This article will cover what a user story is, how to write one, and how they can help steer your project towards a successful outcome. Wireframes will be covered in a later article.
What is a User Story?
A user story describes a small piece of system functionality, in a simple and easy to read sentence. A well written user story will describe what the desired functionality is, who it is for, and why it is useful.
There are 3 parts to a fully fleshed out user story. If you like marketing-speak, then you can call them the “3 C’s”:
- The Card
- The Conversation
- The Confirmation
A typical user story follows this template:
Having such an easy template to follow allows anyone involved with the project to help write them, from sales, to designers, developers and testers, all the way through to clients or users.
We refer to this as “The Card” because often they are written on 3x5 bits of plain card, usually to give a physical constraint which limits the possible length of the story.
Here’s a few hypothetical examples I’ve written for YouTube. I’ve defined a “Creator” as someone who contributes videos to the site, and “User” as someone who just watches them:
As you can see, with such a small statement we gather a lot of useful information that we may not have been provided otherwise, including who we’re doing this for, and what value it will bring. But it’s not the full picture, or enough information to start building things yet. This is where the conversation comes in.
Think of the conversation as an open dialogue between everyone working on the project, and the client. Anyone can raise questions, ask for things to be clarified, and the answers can be recorded down as bullet points for later reference. It is also a stage where you can reevaluate your user story, and possibly split it into multiple stories if required.
For example, we discuss the creator upload user story, and decide that there are actually multiple things that can happen, so we split them, and expand on them:
Once you write a few of these and get into the swing of it, you’ll find you’re getting a lot of data written down very quickly. Because of this, it’s important to organise your user stories in a manageable way. I like to group them by interface, and present them next to a wireframe showing the intended functionality.
The confirmation is basically just a test case. If you’re not familiar with test plans and test cases, think of a test case as a series of steps that a user must do to achieve the User Story. A test plan is a collection of test cases. With full coverage of your system in your test plans, you can easily test every core piece of functionality and tick them off as you go through them.
A test case for our YouTube example might look like this:
INVEST in your user stories
In most places you see user stories being discussed, you may hear the acronym INVEST being thrown around.
It stands for all the things a good user story should be:
It’s only with practice and real world usage of these techniques that you’ll find how useful they really are. If you’re at a company thats stuck in a “waterfall” development mentality, you could try using this information to pitch your boss a more effective method of requirements gathering. If you’re a freelancer, try it out on your next project and see how you go.
I’m interested to hear comments and feedback from any of you that have used well written user stories in your projects and how you found the experience.