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
Acceptance Criteria
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
Top comments (0)