User stories: a comprehensive guide

The term “user stories” is a little misleading. When we think of a story, we often think of a long, drawn-out prose or biography. However, this is not the case with user stories in the agile world, where most are little more than a statement or a sentence that guides us when using our wireframe tool.

In the agile environment, user stories represent a simple, yet powerful technique to help us organize and prioritize our work more efficiently, with the optimum outcome for the user. For this reason, many agile teams use user stories to organize their feature requirements backlog.

In this guide, we’re going to explore just how a user story helps us develop features in a way that maximizes both user and client satisfaction. Well also look at how to put one together in a way that prompts creative and flexible discussion among your team. Sound good? Read on!

User story writing is a technique that’s frequently deployed in agile projects to help build software that solves problems for its users as fast and efficiently as possible. User stories generally consist of a brief statement of a goal from the point of view of a user persona that normally consists of one simple sentence.

The goal the user has in each story represents a feature that we need to build into our product. Agile teams create user stories as they are a way of breaking down feature development into small chunks and prioritizing the features that matter the most.

User stories were traditionally written on index cards but nowadays, it’s also common to find them in both hard copy and digital format.

There are significant tried and tested benefits to working with user stories, otherwise there wouldn’t be many agile teams the world over working with them. Here are some of the main reasons why many agile teams focus on user stories:

One of the main benefits to working with user stories is that they help break down large and ambitious product scopes into manageable feature chunks. User stories are simply a short statement of what the user wishes to achieve in their own words. They help teams avoid getting bogged down in the technicalities and procedures.

User stories are brilliant at helping teams to prioritize which features to build first. When used as backlog items, they can make it easier to organize and divide tasks or feature requirements into sprints.

These backlog user stories can be ongoing requirements that the user needs satisfying. When a new product has a backlog of features to be completed, the backlog items in a tool like Atlassian Jira may look like a quick one or two-sentence user story. The story normally gives some background into the kinds of actions and benefits that each new feature supposedly should have.

User stories also give agile teams a concrete criteria to test with. For example, there should always be a demonstrable result at the end, whereby we can say that a user story satisfies the outcome. In this way, user stories help us to more effectively measure the performance and outcome of our efforts during each sprint.

User stories help us to see the value that certain features will offer our users. With user stories, agile teams can zero in on the most important and immediate features that users need upfront. Hence, they encourage us to work in a more efficient way that’s more profitable for clients and stakeholders and better for the user.

Because user stories lack a lot of the technical jargon normally included in many other product development documents, they open the team up to more creative speculation. It’s therefore a technique that fosters more creative and flexible dialog between development and design teams.

With user stories, we’re not thinking in terms of specs and technicalities, but rather in terms of the product from the user’s point of view, along with how they might use it. In this sense, user stories are also great for non-technical stakeholders who want to understand the direction the project might be taking, and which features are being worked on at any given time.

The other awesome benefit that user stories offer is that they can bring your user personas to life and get these fictional, yet real-life-based people involved in the project.

It’s like having one or two people that represent thousands or millions of users sitting beside the development team and literally guiding them on what they need, rather than the team simply imagining what they need.

User stories can also lead to a productive agile technique called user story mapping, whereby all the stories are gathered together organized to create a development timeline and a priority list.

The way agile teams write user stories often varies across different organizations and teams. To successfully write user stories, you should always take the following elements into account to provide a comprehensive picture for your team of what exactly is needed at each stage of the product development:

• User
• Action
• Benefit

With these three elements, you can write up a brief user story regarding the feature (product requirement) your persona needs and why they need it. We normally write the user story with the following structure:

As a ____ user, I want to ____ so that I can ____.

Let’s say you want to create a social driving app that lets drivers see where their friends are. It also lets them post updates about traffic delays, accidents or weather patterns using their voice. You might fill in the above structure like so:

You might then include what’s called an acceptance criteria (which we’ll delve into more detail on below) that lists out the technical specifications required to ensure the user’s needs are being met. These might include the following:

• App should recognize the user’s voice command to start a new post
• App should read user’s post back to them
• App should ask user to confirm they want to publish
• Notifications should be sent to friends on the network

But what about when you need to write more than one user story, for example? Afterall, your app or website will have multiple features and your user stories will be short. How do you categorize them into sub-features? The answer is by writing epic stories.

Epic stories help you paint a broader picture by summarizing a complex action composed of smaller actions. In this sense, the epic user story is like an overview of a product feature. Epic stories are written the exact same way as user stories, just less specific. Here’s an example:

This epic user story example can then be subdivided into more specific user story examples for the same app, like the following:

Or:

Lastly, you should always write your user stories from your user persona’s point of view. For example, don’t write a story that, in order for it to be tested, another feature would need to first be developed or designed.

When you do this, you stray into dangerous territory which, in the agile world, is called “deadlock”. This is very similar to “checkmate” in chess. It’s where you have nowhere to go. Starting Agile author, Mark Shead, gave the following example of a vague and bad user story during his video Agile User Stories:

In this case, the database would already need to exist, making the outcome of the user story (storing information) codependent on the database.

Many teams that get user stories wrong often end up in this deadlock or doldrums. The client asks them for an update, and they reply by saying that in order to begin developing the app, they must first finish off the “setup work”. But “setup work” should ideally never exist. If user stories can’t kick off the action from the start, then you’re probably doing it wrong.

Great user stories can stand alone independently and also blend in well with others to give a picture of an overall product. Sometimes an idea may not be bad, it’s that it’s presented badly, which is the case with the bad bad user story example above.

First of all, and above all else, before you go about writing up your user stories, it’s vital that you carry out the appropriate user research and define your user personas. Why? Because it’s exactly these user personas who your user stories will be based on.

User personas are the first step to when it comes to writing a successful user story because if you don’t know who the user is, how is it possible to write your story from the user’s point of view?

When it comes to the user story writing technique, there are just three basic requirements you need to keep in mind before getting started. Or perhaps you want to sell the idea to other stakeholders.They are the 3 Cs:

• Card
• Conversation
• Confirmation

The whole point of user stories is to provide a simple statement on a card. Quick and easy. The next “C” is Conversation – the whole point of user stories is to spark creative conversation and collaboration among agile teams. Lastly, the final “C is “Confirmation” which refers to the acceptance criteria that we can test once we’ve built the user story feature.

Additionally, when it comes to writing effective user stories it’s always best to make sure that the feature is measurable and testable. If it’s not testable, there’s no way to show if the feature is truly satisfying the user’s goal. There’s also no way to truly demonstrate the functionality of new features.

One way to decide if a user story feature is testable is to write acceptance criteria for each one you create. Sometimes, the acceptance criteria might include a list of several variables that must be true after the feature is developed. An example might be:

The acceptance criteria could be something like the following:

“After registering, user should be shown an option on the login screen to log in with their Google account.”

Sometimes, just from reading the user story itself, it might be obvious what the acceptance criteria should be. However, no matter how short or how long, it’s always good practice to write out your acceptance criteria. This prevents your team from falling into lazy habits and never writing any. It’s best to already be thinking of the acceptance criteria when you’re writing your user story.

If you can’t think of an acceptance criteria then that means the feature cannot be tested. This means you might want to rethink that particular feature.

If, on the other hand, you find that the acceptance criteria is too long to even be included on an index card, then you should consider breaking it up into another user story or perhaps it should be an epic story instead. These are all things you can think of when it comes to writing acceptance criteria.

The INVEST method is a great rule of thumb to guide you towards writing the best user stories possible. The INVEST method is a mnemonic for the following best practices:

User stories, although often included in epics, should be understandable as stand-alone pieces as well.

User stories should offer a large degree of flexibility. This is why they shouldn’t include specific technicalities. Afterall, flexibility is the nature of the scrum environment.

The user story should offer value, both to the team and to your user personas. It should give your team a clear idea of the goals of a feature they have to design and develop. And for the user, it means a product that consistently meets their needs.

It should be possible to estimate the amount of work needed for a feature proposed in a user story. This will help you assign the relevant scrum points to the backlog task and manage time effectively.

A user story should be short and memorable. Just two lines about what that user wants to achieve with a specific feature of your product. If it is an overall description of your app or category of features, then write an epic and break it down into sub-stories.

The user story should ideally fit into one iteration. You also shouldn’t mention any specifics about UI design in a user story.

Like with most things in the development process, your user stories should be easily testable with clear deductible metrics for key performance indicators. This is usually where the acceptance criteria come into play.

Next, the best thing that we can advise when it comes to regularly writing great user stories is to use a template. It’s a brilliant way to ensure that you and anyone on your team who writes user stories is always covering the who, the what, and the why. These are the details you need to ensure you capture all of the necessary information in the most concise way possible.

There are many useful digital templates out there that can also be printed off or used in Jira or another kanban system. But the great thing is that templates can also have many other fields that can be useful, such as scrum points and an area to write your acceptance criteria.

Using a template for epics that is composed of many sub-stories can also be a great way to organize a series of micro-features revolving around one greater macro-feature.

Candidate stories are an optional step when it comes to writing user user stories. These are the stories that your team writes first to kick off the process when you’re trying to ascertain what it is the user wants based on their personas.

This optional step can be a great way to brainstorm using physical index cards in a meeting. Candidate stories don’t even need to follow the typical structure of real user stories. Successful candidate stories that your team produces can then be further developed into the real user stories.

In a nutshell, user stories help your team focus on what matters most to the user. What’s more is that teams working in an agile environment can benefit enormously because it’s a technique that allows us to organize work efficiently.

When creating a user story, you should always make sure you have defined your user personas first, and keep in mind the 3 Cs. The INVEST method is a handy guide to ensure that you’re turning out the best user stories possible for your team.

Lastly, and most importantly, for the best results, we recommend keeping your user stories simple and obeying the typical sentence structure we mentioned in this guide. Time to get that ink wet!