To view the article on Medium click here.
If you’re reading this article you’ve probably come across what User Stories are and you now want to understand how to write good quality clear ones that anyone can understand.
Well, you’re in the right place!
Let me introduce you to a Business Analysis standard commonly known as User Acceptance Criteria, a simple structured English format that’s used in the Agile world.
As you may know, a typical User Story format takes the following format:
As a <Persona>
I want to <An action>
Such that <I get something in return>
It will be a success when <Definition of success>
Or something more real — might be
As a <Bride>
I want <to contact a wedding planner>
Such that <they can organise my wedding>
It will be a success when <I have no stress and everything goes to plan!>
This articulates all the tasks that needed to happen before, during and after the event to make it zero stress. In this example, you would essentially have written all the Acceptance Criteria to a successful wedding.
If you’re thinking, how do I start? Acceptance criteria typically specify the conditions under which a user story is fulfilled. The Acceptance Criteria of each User Story will be different based on the conditions a story has to meet to be completely delivered. The difference between a User Story and Acceptance Criteria is that a user story describes a high-level description of a function, outcome or activity and its benefits. Acceptance criteria are the detail items/activity that the user story has to meet to regard the story as ‘Done’!
Now you’re talking my language!
The following format below is used in Agile and is known to us in the industry as Behaviour-driven development format, nicknamed BDD. It’s typically broken down into the following 3 sections:
Given <Setting the scene> (The precondition)
When <The thing we are testing> (The Trigger)
Then <The expected outcome(s)>
And <Used to continue any of three previous statements> (Optional)
It doesn’t look techie and complex I hear you say. Well, that’s because simplicity encourages collaboration between technical and non-technical individuals.
In essence for most people to understand. We like instructions to be simple, BDD gives you the method to define what you think needs to happen in a simple structured manner being very specific about the precondition, trigger and action. It has a close relation to the familiar cause-and-effect familiarity that we all understand and know from our daily lives. Below are two examples:
Example 1: No stress for the bride getting to the limo.
Given <it’s my wedding day>
When <the limousine arrives>
Then <park the car outside my house>
Example 2: Ensures that the bride is not stressed
Given <it’s my wedding day>
When <the make-up artist arrives>
And <the hairstylist arrives>
Then <send them both up to my room to get started >
Etc…. As you can see it’s dead simple!
The subtle omission of ‘When’
The following example has been created for the more advanced among you taking the Amazon registration process as an example. In this example, a user attempts to create an Amazon account where the trigger (when) is incorrectly omitted. The use of the ‘And’s instead causes confusion, though it is subtle:
Given <I’m on the sign-up form of the Amazon home page>
When <I enter my First Name>
And <Last Name>
And <Email>
And <Password>
And <I submit the Form>
Then <an account is created>
And <account name is set as my Email>
And <a confirmation email is sent to my email>
Note: the overuse of ‘And Then’ is also frowned upon!
In this scenario, there is no clear idea of what ‘Tigger’ is to be expected to be tested.
Here’s an improved example:
Given <I’m signing-up for my Amazon account>
And <All mandatory info has been supplied: First Name, Last Name, Email, Password>
When <I submit the Form>
Then <An account is created>
And then <Account name is set as my Email>
And <A confirmation email is sent to my email>
From this improvement, now we can see there is a distinct ‘When’.
Not generic enough
In this scenario, a user attempts to select a train without assigning the seat, however, the Acceptance Criteria is not generic enough to be used in any interface. A good Acceptance Criteria can be used regardless of how the requirement is implemented via the online site, Alexa or at the station itself.
Given <I have selected a train time at the Train time selection page>
And <I chose to skip seat selection at the Seat Selection page>
And <I selected a meal at the Meal Selection page>
When <I confirm my details on the Confirm Details page>
Then <A warning message should appear “Your seat will be assigned randomly to proceed?”>
Here’s an improved example:
Given <I have selected a train time, on the Train time table provided>
And <I have chosen to skip the seat selection>
And <I have selected a meal>
When <I confirm my details>
Then <The following warning message is displayed to me “Your seat will be assigned randomly. Do you wish to proceed?”>
As you can see the refined Acceptance Criteria now addresses all channels of communication making it non-techie and unbound by any implementation decision the developer may wish to use.
Writing better acceptance criteria will help keep your non-technical colleagues from losing their focus, bring your user stories to life and create an unparalleled level of understanding for the conditions under which a story needs to be fulfilled.