Understanding User Stories and Acceptance Criteria

What is a User Story?

Simply put, a user story is a short, informal and simple to understand description of a single software feature or function. The purpose of user stories is to explain the roles of users, what they need to do and what they want to achieve. 

Written from the user’s perspective, user stories might be written by clients, managers, users or developers and Agile teams use them as the primary method of identifying user needs.

“User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality” – Mike Cohn, contributor to the Scrum software development method.

Although variations exist, user stories tend to be written in the following format: 

As a (type of user), I want to (perform some action) so that I can (achieve something).

Following this format, some real-world user story could include:

• As a Customer, I want to receive a text message so that I know when my item is ready to collect.
• As a Sales Manager, I want a sales dashboard so that I can see this month’s stats at a glance.
• As an Office Administrator, I want a to-do list, so I can see an overview of my workload.

INVEST

INVEST is an acronym coined by Bill Wake in his book Extreme Programming Explored. It defines a simple set of rules used in creating well-formed user stories.

A good user story will be:

• Independent: stories shouldn’t depend on any other stories
• Negotiable: stories should capture the essence of a user’s need, leaving room for conversation
• Valuable: stories should clearly illustrate value to the customer
• Estimable: stories should provide just enough information so they can be estimated
• Small: stories should be granular in scope so they can be completed in as little time as possible
• Testable: stories have to be confirmed via pre-written acceptance criteria

The 3 C’s

A user story has three primary components (Card, Conversation, and Confirmation) to describe the three elements of a user story.

Card

A card or Post-It note (or the digital equipment) is used to record the user story text. The card serves as a memorable token, which summarises the intent and represents a more detailed requirement, whose details remain to be determined. 

Conversation

A collaborative conversation is facilitated by the Product Owner and involves all stakeholders and the team. This conversation, although mostly verbal, can be supported by documentation and automated testing. 

Confirmation

The Product Owner must confirm that the story is complete before it can be considered ‘done’. The definition of ‘done’ is driven by acceptance criteria, which we’ll come onto next. 

What are Acceptance Criteria (AC)?

Acceptance criteria accompany user stories and are the conditions software must meet to be accepted by a user, customer, or another system. They are unique to each story and one user story can have multiple acceptance criteria depending on the complexity of the function or feature. Well-written criteria help to avoid unexpected results and ensure that users and stakeholders are satisfied.

Acceptance criteria usually fall into one of two types: Scenario-Orientated and Rule-Orientated. 

Scenario-Oriented AC

Also known as the Given/When/Then (GWT) type, scenario-oriented acceptance criteria tend to follow the structure:

Given some precondition

When I do some action 

Then I expect some result 

Each acceptance criteria written in this format will contain the following statements: 

1. Scenario – the name for the behaviour that will be described
2. Given – the beginning state of the scenario
3. When – a specific action is taken
4. Then – the outcome of the ‘when’ action
5. And – used to continue any of the three previous statements

Example user story: 

“As a customer, I want to be able to reset my password so that I will be able to login if I forget my password”

Example acceptance criteria:

• Scenario: Customer forgot password
• Given: The customer has navigated to the login page
• When: The customer selected the reset password option
• And: Entered a valid email to receive a link for password recovery
• Then: The system sent the link to their email address
• Given: The user received the link 
• When: The user navigated through the link received in the email
• Then: The system enables the customer to set a new password

Rule-Oriented AC

If acceptance criteria won’t fit into the Given/When/Then format, rule-orientated AC can address this. 

Example user story: 

“As a holiday-maker, I want to use a search field to type a city so that I can find hotels in my chosen holiday destination”

Example acceptance criteria: 

• The search field is placed at the top of the page
• The field contains grey placeholder text, ‘What city are you visiting?’
• The placeholder disappears when the user starts typing in the field
• The user can’t type more than 100 characters
• The search starts when the user clicks the ‘Search’ button below the search field
• Search is in English

The Main Purposes of Acceptance Criteria 

Detailing Feature Scope

The boundaries of user stories are defined by the accompanying acceptance criteria. The precise details AC provide help the team to understand if the story is complete (‘done’) and works as intended and expected.

Describing Negative Scenarios

A negative scenario could be described as invalid inputs or unexpected behaviour on the part of the user, such as an invalid password format. Acceptance criteria help to define these scenarios so that fault tolerance can be built into the software at every stage. 

Aligning Understanding

AC help to ensure that stakeholders, clients, and the development team all have a common understanding of what is needed and expected. Developers understand what behaviour must be demonstrated and clients and stakeholders understand what’s expected from the feature. 

Streamlining Acceptance Testing

Acceptance Criteria form the basis for acceptance testing. Each criterion is independently testable and has clear pass/fail scenarios.

Estimation

The precise requirements provided by AC allow the team to split user stories into tasks that can are simple to estimate correctly.