Writing Effective User Stories

“After nourishment, shelter and companionship, stories are the thing we need most in the world.”

~ Philip Pullman

Stories are how we understand the world around us and the best stories are told in simple terms. But before you can write effective user stories, you need to know what a user story is.

What is a User Story?

A user story is a description of a feature written from the perspective of the end-user.

Not from the perspective of the developers and what they think is feasible. Not from the perspective of the Compliance Team and what they think the internal policy is.

Typically, a user story is written in the format below:

“As a ______________, I want to _______________ so that ______________

(type of user) (action/want/need) (reward/goal)

The beauty of this format is that it forces the writer to be concise enough while still communicating clearly; much like the character limit on Twitter.

From looking at a well-written user story, you can tell who the user is, what she’s trying to do and what her intended goal is.

Note: User stories are sometimes simply called “stories”

Some examples:

1. As a user, I want to enter my email address and password so I can log in to my profile.

2. As a premium user, I want to see a list of exclusive holiday deals so I can make my pick.

Whose Job is it to write the user stories?

It is important to note that anybody in the team can (and should?) write the user stories but in reality, the Product Owner/Manager usually writes them. Maybe that’s the Engineering team’s way of avoiding additional responsibilities or the product manager’s way of claiming to understand the end-user better. It doesn’t matter. The most important thing here is for all to understand that anyone can and should write user stories.

To ensure that everyone knows whom to write user stories and what it means to the project, many agile teams organize a user story writing and discussion session at the start of a project.

An important but often overlooked aspect of user writing is the discussions of the user stories. Ideally, after user stories are written the team gets together to discuss them. This helps everyone on the team understand what the intentions and desired outcomes are; making sure that all ambiguities are cleared out and making sure that the features are in line with the product roadmap and it’s actually what the user wants/needs.

User stories can be written on anything from a piece of paper to sticky notes and anything else of your choosing. However, the use of software such as Jira and Visual Studio by Microsoft and the likes have almost taken over how user stories are written.

Parts of a User Story

Every story, be it in software or in the general society, has different parts. This helps to make the story more interesting and relatable.

User stories are no exception.

A good user story can be broken down into the following parts:

• Description- recall our user story format? This is where you describe the feature from the perspective of the end-user
• Acceptance Criteria- this is a condition or a set of conditions that must be met for a feature or functionality to be considered done. The acceptance criterium is sometimes called “Definition of Done”

Ambiguity must be avoided at all costs when writing acceptance criteria.

From my experience, acceptance criteria are better written as bullet points; with each point speaking to a single condition of acceptance.

Let’s create a quick example for a story for login to an app:

Story: As a user of XYZ app, I want to enter my email address and password so I can log in

Acceptance Criteria:

• The email field should be clearly marked
• The password field should be clearly marked with the password conditions clearly shown by the side
• The password field must be alphanumeric, contain at least 1 special character, and be a minimum of 8 characters long
• Password is case sensitive
• Email address is NOT case sensitive

Acceptance criteria help the:

Developer to know what to focus

Quality Assurance tester to establish basic testing conditions

Product Owner/Manager to easily and quickly validate that the user’s expectation has been implemented

It doesn’t matter who writes the acceptance criteria but the Product Owner or Manager is ultimately responsible for ensuring that it is written and written as clearly as possible.

• Business Rules- sometimes a user story would have some conditions or rules that govern it. Essentially, business rules are a set of policies/regulations/conditions, typically, imposed by the business/organization or regulators as a means to shape behaviors on a broader level

A good example of a business rule would be placing age restrictions on some websites. In most countries, sports betting has a minimum age requirement of 18 years set by the gambling regulators. A good business rule, if you were building a gambling site, is to check for the user’s age during onboarding.

Story: As a user, I should be able to enter my personal data so I can sign up on ABC Sports Betting platform

Acceptance Criteria:

• Users must provide their first and last name
• Users must enter their email address and mobile number
• Users must provide their date of birth in this format DD/MM/YYYY

Business Rule:

• Only users who are 18 or more years old would be allowed to sign up
• Users who are below 18 years of age should be shown the message “You are not eligible to sign up until you are 18 years or older”

All user stories do not necessarily have to have business rules and with many software solutions for writing user stories, this is usually optional. Some product owners/managers prefer to have every condition under acceptance criteria.

Somehow, this post ended up a bit lengthy but I hope you found it helpful.

Got questions? Message me on nnamdi.azodo@gmail.com