User Stories — Why we write them and how to get started!
A beginner’s guide to the origins of, reasons for and first steps you can take to write user stories.
Back when I first became a business analyst, we used to create big catalogues of user requirements and work for weeks and months to turn them into a clear view of everything that we wanted an IT system to do.
They would sound a bit like this…
“The system must accept the entry of the customer name into the registration screen.”
“The system shall have an interface to the payroll system to carry updated staff details.”
We would then add a bunch of acceptance criteria and put it in a big requirements catalogue along with all the other requirements. The catalogue would either live in a requirements management tool, or a big excel spreadsheet or a software requirements specification document.
Each one of those requirements would then be met by writing down how it was to be delivered in a functional specification document that stated exactly how the system should behave for all the requirements in the catalogue. At some stage, someone would have the awful job of checking off that the functional specifications covered each and every requirement and would ensure that there was a way of tracing from requirements from the catalogue through the the finished code (and sometimes as far as training documents).
It all made perfect sense, simply define everything you wanted the system to do and make sure that, when you built it, everything that you’d asked for was delivered and tested.
The problem was that it’s very difficult to predict everything that a system needs to do up front. As a result, missing requirements would be identified late in the project and had to be shoe-horned in. Sometimes things were missed because they just weren’t thought about, other times new requirements would emerge whilst things were being built, for example a new bit of legislation could change all sorts of things.
Quite often projects were cancelled with no benefit being delivered to the business who had paid for them. The statistics were startling and people spent huge amounts of time trying to find a better way to run software projects.
Back in 2001, a bunch of software industry people got together and worked out a series of principles that they called the “agile manifesto” that outlined a series of principles that they believed would improve software development. Among the values they adopted were valuing human interaction over processes and tools and valuing working software over comprehensive documentation.
The agile approach was based on acknowledging that the old approach of “plan the work and then work the plan” didn’t cater for the ‘unknowns’ that were inherent in software development. Instead the agile pioneers agreed that the only way to handle this uncertainty was to react to changes that were bound to happen.
As they said in their manifesto
“We are uncovering better ways of developing software by doing it and helping others do it”
As a part of this attempt to change the way in which software was written, they adopted a number of software engineering practices that had been introduced as a part of the Extreme Programming approach; one of these practices was the use of User Stories.
What is a User Story?
At this point, let’s take a moment to look at the general format of a user story. One of the values of the Agile manifesto is that agile practitioners value “Individuals and interactions over processes and tools” as a result, you’ll be unsurprised to find that agile teams are encouraged to adapt the tool they use to suit their circumstances; user stories are no exception.
As such, you may find that different teams adopt different ways of writing User Stories. However, there is a generally accepted format that is almost universally used.
The format is;
As a… (who is the user or customer?)
I want… (what are they trying to achieve)
So that… (why do they want the thing they want?)
Let’s take a look at a worked example. In this article, I’ll try to use “real world” examples that you can relate to, so let’s start with a example from YouTube.
As a video subscriber,
I want to be emailed when a new video is uploaded by someone who’s channel I have subscribed to,
So that I can watch their new video.
Let’s break that down a bit. The usual format is
As a, followed by the name of the user, type of user or their persona
I want, some kind of system goal
So that, why the end user wants the goal
In the case of our YouTube example, the user, who has been labelled a “Video Subscriber”, wants to receive an email when a new video is uploaded by one of their favourite YouTubers. We’ve also included why they want this; in our example, it’s so they can watch the new video.
As you can see, the User Story has covered, in plain language, who the functionality is for, what the functionality does and why they want it. Each one of these elements is important.
Let’s take a moment to consider the old way that the requirement could have been written,
“The System shall send an email to a subscriber when a new video is uploaded”
As you can see, the more traditional method probably wouldn’t have mentioned who the functionality was for and why they wanted it.
There are other formats of user story that have been proposed over the years, but the other versions are not widely used so you won’t go wrong using the normal approach. There’s a short download attached to this section where we have gathered together some of the other formats that exist.
Your first user story
OK, let’s get you writing a user story. As with most things in life, writing good user stories with confidence is all about practice, so we’ll be encouraging you to write user stories to get some practice.
Let’s write another YouTube example. Have a go at writing a user story for a user to add a YouTube channel to their list of subscribed channels. Remember, use the format “As a, I want, so that”.
Go on, stop reading and have a go.
OK, then, let’s carry on…
You probably came up with something like this.
As a logged in user, I want to add a channel to my subscribed channels list, so that I can keep track of channels that I want to follow.
As a user, I want to subscribe to a channel, so that I can get notifications when new videos are uploaded to the channel.
You might even have said,
As a YouTube customer, I want to be able to ‘favourite’ a channel, so that I can find it again in my favourites list.
One of the things that we discover when working on “real life” projects is that there is often no right or wrong way, just a series of techniques and best practices that can be followed. So, if you got something like the example above you’re heading in the right direction. We’ll go over various best practices as we go forward, but here’s mine.
As a logged in user, I want to subscribe to a YouTuber’s channel, so that I don’t miss their new videos.
Each one of these examples could work as a user story, but there’s more to it than simply following the “As a, I want, So that” format. In the next section we’ll take a look at why the user story approach is widely used.
So, why User Stories?
On the face of it, traditional requirements and user stories aren’t that different. In both cases, we’re just trying to express something that we want to build. Sure, the user story includes the additional information about who the functionality is for and why they need it, but the essence is the same.
So why are user stories seen as superior? Well, they add the following value over traditional requirements;
- They use a storytelling format that engages us as humans. No one cares about being able to stop the system with a single press of a button in isolation, but when you add in the information that James Bond wants to be able to press the button to prevent the release of a deadly disease in Central London, then suddenly we begin to care.
- They help us to keep the end user in mind — As we’ve seen, the user is explicitly stated at the beginning of the user story.
- They convey the intent behind a requirement as well as the content — The reason the user wants the functionality is stated in order to guide the developers in designing appropriate solutions.
- They are focussed on the value that the end user wants — They help us to see why each requirement is important and allow us to measure if the requirement’s objectives have been met.
- They are understandable and written in plain language — They allow a cross-functional team, ranging from business users through to technical staff to understand the requirement in a common language. Even people who have never seen a system requirement in their lives can grasp the idea and practice of a user story — they may not be good at writing them, but the concept isn’t hard and can start a conversation.
All well and good, but user stories have other super powers but these come into play when they are used as a part of an agile project. You will get some value from using the user story format on traditional waterfall projects but you will unlock more value from using them on agile projects.
These additional user story advantages that come into play on agile projects are;
- They each cover a separate bit of functionality and can be prioritised independently — instead of all the requirements being delivered at once, different versions of the product can be released at different points.
- They can exist at varying levels of detail. It is possible to sketch out a whole system very quickly in order to create a complete backlog and get a feel for the scale of the product
- There is no need to define what is in or out of scope before you understand more about the product. Speculative functionality can be sketched out, even if it’s not prioritised; this way ideas are not lost. This encourages iterative thinking as the product owners are pushed to think about which parts of the backlog deliver the most value.
- They allow you to defer details — it is often best to define the details of a particular aspect of functionality as late as you can as you will know more as you go along.
- They encourage verbal communication — Agile teams work together to deliver functionality; user stories assist this by working as a vehicle for communication.
- They allow iterative development — It is possible to have several versions of the same functionality that are delivered over the course of a product lifecycle.
Agile projects follow the agile principle that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” The idea of user stories taps into a number of human characteristics that support this principle; we communicate naturally through storytelling, we communicate best when face to face and we are good at using our imaginations to empathise with other people.
Within an agile project, the product owner brings a user story to the team and engages in a discussion about what the user story is all about. The team are able to ask questions and evolve their understanding of the requirement before and during the build process. Finally, they demonstrate their finished functionality back to the product owner and other stakeholders so that they can show what they have achieved. But that’s a story for another day.
So now you know why we write user stories, the benefits they have over requirements catalogues and a little bit about their value to agile teams. Good luck getting started with writing user stories.
Oh, and one last thing; the best way to get better at writing user stories is to write them, so practice as much as you can and share your examples with other people so they can help you!
If you’ve not got anyone available, maybe try the comments on this article to see if I, or someone else, can help…
Finally, here’s another example…
As Chris, I want you to sign up for a Medium membership using this link, so that I feel supported in my writing and get a small commission as a thank you from Medium.
If you do sign up, you’ll get get unlimited access to all the stories on the platform as well as all the articles I put on here.