Analysts who embrace user stories can improve results

User stories aren’t features. They represent what users want to achieve in simplest terms – and they shape results accordingly.

In Brief

• User stories crystallize what people hope to achieve when interacting with a software solution.
  
• By building solutions around well-defined user stories, you can vastly improve the way people interact with and experience an app.
  
• This keeps people engaged, compels them to act and fosters better results.

The business analyst’s guide to writing user stories

What is a user story?

A user story is the smallest unit of work in an agile framework. It’s not a feature, but an end goal that the user has when using the software. The user story will convey what the user wants to achieve and states it simply, non-technically.

Why should I use them?

After reading a user story, the team knows why they are building a feature and the value the feature creates for the end user. Knowing the value of the feature helps create the best user experience possible, ensuring that the user can accomplish their goal with the application.

At EY Design Studio, we find user stories beneficial because:

• They focus on the user and their needs. Stories keep the team focused on helping resolve problems for real users and ensuring they’re able to accomplish their goals. This purpose can often get lost if there’s a checklist of other to-dos.
• They allow for equal amounts of understanding and collaboration. When the client’s requirements are written in a way that can be understood by the developers, and the user’s end goals are described in laypersons’ terms for project managers, stakeholders and clients, the team can work together more cohesively to deliver the best solution for the user.
• They drive creative solutions. User stories don’t explain how the user will achieve something, just what they can accomplish from doing it, which enables developers to implement solutions in whichever way best helps the application and the end user.

When do I use them?

User stories are written throughout the agile project. However, the business analyst assigned to the project should produce user stories in the discovery phase. After the discovery phase, everyone on the team will then participate to create a product backlog of user stories. This backlog will fully describe the functionality to be added over the course of the project. In an agile project, new stories can be written and added to the product backlog at any time, by anyone.

How can I make one?

There are four steps to creating good user stories. These steps require the collaboration of the client and the business analyst on the project:

1. Validate the needs of the users

The client first must clearly define the users who will use the application. It is very important to know the user, their pain points, needs and goals. You should typically have a solid understanding of your users, but no matter how well you think you know them, there is no substitution for performing market research and interviewing potentials users, both before and during the discovery phase.

Because this is so integral to the process at EY Design Studio, we offer market research as a service and will often encourage our clients to collaborate with us for this. The business analysts work with UX researchers to deliver focus groups, perform interviews and compile other findings to create data-driven user experience maps and user personas.

2. Create epics

Epics can be described as a major component of the application. They are generally drafted before user stories are written to map out the bigger components, but are also further defined as more user stories are identified. User stories are then grouped into these epics. Organizing user stories into epics is useful for planning what features developers will build and in what order, and it can give a high-level understanding of the features of the application.

An example would be creating a “login” epic, and having all user stories related to login under that epic, such as:

• As a user, I want to login so I can access the application.
• As a user, I want to login with my Facebook account so that I can login more quickly.
  

3. Writing user stories

After the users and the epics have been defined, the business analyst on the project will begin drafting user stories. Epics can be added and removed as different components are identified. This step can also be done collaboratively with clients if they are interested in contributing.

User stories typically follow a simple template that captures the user, and the user’s goal , in a simple and non-technical format.

As a < type of user/role >, I want < some goal > so that < some reason/benefit >.

4. Defining acceptance criteria

Acceptance criteria are used to define the specifics of a user story and are written in clear, non-technical language. Developers use these details to better understand the deeper details and requirements of the user story. Testers also use the acceptance criteria as a checklist when testing the application.

Acceptance criteria are often defined first by the business analyst, and when the project moves on to development, it is further defined by the whole team. When developers contribute to acceptance criteria, it ensures the details of the user story are feasible and can be effectively implemented.

At EY Design Studio, when writing acceptance criteria, we try to remember two important things:

• Define it before development starts. It’s important to define the acceptance criteria before a user story starts being developed. That way, we’re more likely to capture the user intent, rather than the development reality. If it’s done after the fact, all we have achieved is a list of what is currently there, whether or not it solves the user’s problem or addresses their need.
• Remove all ambiguity. It’s important to consider edge cases — like “what if they log out in the middle of a transaction?” or “what if they want to use the app in a different time zone?” — and ensure each route is thought of. This creates the best user experience and allows for the most comprehensive test coverage.

What does a completed set of user stories look like?

The following is an example of a document we create in a project’s discovery phase. We work in Google Sheets because it allows very easy collaboration between the team and the client. As you can see, not all user stories have a “so that…” section, because the user story itself can be self-explanatory. But other times it can add another level of understanding about the user’s goals.

Here’s what a set of user stories could look like.

Overall, user stories are a key part in creating a useful user-oriented application. As long as you have a very clear understanding of your users, you will be able to create a great set of user stories that outlines the goals a user has for your application.

At EY Design Studio, detailed and comprehensive user stories are one of the pillars in our discovery process. We can perform extensive user research and interview stakeholders when creating user stories, which helps us achieve the desired business value and desired objectives for your mobile or web application. Research and analysis are part of what make our process comprehensive and enable us to deliver great results on every project.

Reach out to us to learn more about how we can create a remarkable digital experience for your users.

Let’s get started on your user stories today.