Analysts who embrace user stories can improve results

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 >.

We also use a handy acronym, INVEST, to remember leading practices of writing good user stories.

A good user story should be:

• Independent: Developers should be able to implement the user stories in any sequence.
• Negotiable: Stories should avoid too much detail and be kept flexible.
• Valuable: Users get some value from the story.
• Estimatable: The team can use them to plan project timelines.
• Small: Smaller user stories are easier to estimate than larger ones.
• Testable: Everyone should be able to document the “definition of done” (how we know the user story is done) and the acceptance criteria.

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.