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