User Stories 1.0

Dimitris Tyflioris
3 min readMay 28, 2022

--

As the adoption of Agile software development methodologies tends to become the norm for the vast majority of modern implementation teams, the usage of user stories for capturing requirements is considered as a standard practice. Therefore, in this article we aim to provide some tips and tricks in order to facilitate the effective usage of user stories and maximize the amount of value that they provide in the achievement of the penultimate goal, which is always to produce a software product of high quality that will meet its user requirements.

What is a user story?

A user story is a description of a software system’s feature that is written from the perspective of an end user.

The format of a user story typically follows the following template:

For example, a user story for an airline tickets application could be the following:

“As a traveler, I want to do an online check-in for a flight, so that I can fly to my destination without having to visit the airport check-in kiosk.”

Tips and Tricks

A common mistake in the creation of a user story is the lack of the rationale, by skipping the “so that” part. However, the necessity of the reason why the user needs to achieve the goal that is described in the user story is crucial and plays an important role in the story’s prioritization and in the overall understanding of constraints.

Another tip for a user story is to keep it simple and small. The simplicity will enforce the user story’s clarity, while its small size will facilitate the story’s easier management throughout the sprint.

Acceptance Criteria

A best practice that should be followed during the refinement of a user story is the specification of a set of acceptance tests. These tests which are typically named as “Acceptance Criteria” collectively describe the story’s conditions of successful implementation.

The most commonly-used format options for the acceptance criteria are listed below:

Option 1: Describe tests via a Boolean statement (T/F)

“The system triggers an alert if the field of passport number is empty.”

Option 2: Make sure that…

“Make sure that the system will trigger an alert if the field of passport number is empty.”

Option 3: Given / When / Then

Given _______ (Preconditions)
When _______ (Trigger event)
Then _________ (System Behaviors)

“Given the user has clicked the check-in button,
When the field of pasport number is empty,
Then the system will trigger an alert.”

Bear in mind that the acceptance criteria don’t have to be rigidly precise. Their main purpose is to provide a holistic overview of the requirement and to potentially facilitate the story’s “definition of done”.

--

--

Dimitris Tyflioris

IT Business pro with a passion for Agile Software Development. Committed to lifelong learning and always seeking new ways to grow personally and professionally.