User Stories 101
Tags: agile, beginners
Published: 2022-09-27 10:27:24

## What is a User Story? 📖

A “user story” in software development is an informal description of a user’s requirement, written in natural language relevant to the business domain, preferably without reference to the software in use (although sometimes this may be necessary), and worked on by a software development team.

It should also ideally be written by (or at least in collaboration with) a user, though they are also often typically written by a Business Analyst or Product Owner, and really can be written by anyone, if they have the right information on the business context.

User stories are conversation starters and anchor what a solution needs to facilitate, but they don’t define it. You may even be able to achieve what you wanted to in your user story without software development!


## User Story Formats 🃏
User stories are often produced in a formatted fashion, largely to drive consistency or to help people to structure their thoughts, but they don’t have to be.

Typically at Advanced (and in many other software companies), user stories follow the “Connextra” template:

> As a user persona
> I want capability
> So that business benefit

The lightweight nature of this format makes it useful in different contexts; on a project management tool like Jira, or physically, on a post-it note or index card.

The key part of any user story is the business benefit (or the “So that” on the Connextra template); if you can’t define why a user wants a capability in your software or process, you probably don’t need it at all!

## User Story Splitting 🕷
User stories should be as small and self-contained as possible in their scope. This is both to ensure a focussed solution and to plan work in manageable chunks. 

There are multiple methods of splitting user stories, but the most commonly used is SPIDR:

> **Spikes**
> Investigations and prototyping to better understand the ideal solution for a user story.
> **Paths**
> Different routes a user may take through a process, e.g. reschedule an appointment, or cancel it without rescheduling.
> **Interfaces**
> Different devices, browsers, or alternate interfaces for different types of users of the system.
> **Data**
> Different categories of information being managed or browsed, e.g. displaying someone’s allergies, or displaying their medication.
> **Rules**
> Constraints on the system, e.g. rules on the maximum number of appointments someone can have booked at once, or a minimum gap between appointments.

## Acceptance Criteria ✅
Acceptance criteria are often added to user stories to determine conditions which need to be fulfilled when implementing the story such as to make it acceptable to the customer. These are used to inform the test cases that are run to verify that the conditions to fulfil the user story have been met.

These may take the format of simple bullet points, or use the “Given, When, Then” template (also known as Gherkin):

> Given pre-condition
> When user action
> Then outcome

## Example User Story 🔍
**As a** District Nurse
**I want** to be able to view a patient’s allergies when visiting them in their home
**So that** I don’t prepare them food or medication that may be dangerous to them

<u>Acceptance Criteria</u>
**Given** a patient has any currently active allergies in their clinical record
**When** I open the patient’s visit on my tablet or phone
**Then** I will see them listed, with the causative agent, reaction severity and description shown