A complete guide to user stories. Told in our own words based on experience working in this space since 2007 across multiple clients and businesses. Pre and Post WORKSHOP IT.
What is a User Story?
A user story is an informal explanation of a software feature written from the perspective of the end user.
It is not a system specification. Nor is it just an extract of your business requirements document but written in conversational language.
It is a tool used to capture what a user wants to achieve, why they want to achieve it, and the value it brings to their lives or workflows. Most importantly, they are always an end-to-end, distinct piece of functionality.
Think of a user story not as a contract, but as a conversation tool between business stakeholders, product managers, and developers. The idea is that someone with only a basic knowledge of what is going on can walk in to your office, pick up a user story and understand what it is trying to achieve.
By having user stories focus on pieces of functionality, it allows for conversations which focus more on value. Prioritisation, product roadmaps and planning all become easier to explain and manage.
History of User Stories
Even today, some older colleagues roll their eyes when they hear Agile, Scrum or User Stories mentioned.
There was a time when every big business thought that Agile was going to change the world and save them a lot of money. Businesses rolled out the processes without changing their underlying culture – which caused some implementations to fail. There are some people who witnessed this at the time, have never fully trusted Agile and still think of it as a passing fad, even though it is now 15-20 years since.
Even before that hype period, user stories had actually been around for a while and didn’t just appear overnight. They evolved as a reaction to the heavyweight, bureaucratic software documentation of the 1980s and 90s.
The concept originated way back in 1998, with Extreme Programming (XP), when Kent Beck introduced them as a way to get users to describe needed features using their own words. Instead of a massive, rigid specification document, developers used physical index cards to capture these snippets of user needs.
Kent Beck you may recognise as one of the founders of the Agile Alliance and co-creator of the Agile Manifesto. I know his name because we had the manifesto pinned on the wall at work for years so I spent many a boring meeting staring at the manifesto thinking how much the image looked like a nativity scene.
In 2001, Ron Jeffries (another co-creator of the Agile manifesto) introduced the famous “3 Cs” formula (Card, Conversation, Confirmation), which shifted the focus from writing requirements to talking about them. And in 2004, Mike Cohn published User Stories Applied, cementing them as the gold standard for requirements gathering across Scrum, Kanban, and the wider Agile world.
Why Do We Use User Stories?
Traditional requirement documents often fail the human element of product development. They are also extremely boring yet intensive to read.
The benefits of user stories are:
- A User-Centric Focus: They force the team to think about real people solving real problems, preventing features from being built just for the sake of cool tech
- Shared Understanding: They encourage collaboration. Developers, designers, and business analysts talk through the story together rather than reading a static document in isolation. When discussing a user story, it is often the the small, clarifying questions that come up along the way that provide the most conversational value
- Flexibility & Agility: Because they are high-level at first and don’t mention the tech solution involved, they can pivot easily if tech constraints or market needs change before development begins
- Manageable Delivery: They break down massive systems into thin vertical slices of value that can be designed, built, and tested in a matter of days
When to Use a User Story
User stories are ideal whenever you are delivering user-facing value in an iterative (agile) environment. Use them when:
- You are building a new product, app, or website from scratch.
- You are adding functional enhancements or new features to an existing product.
- The exact technical solution isn’t fully defined yet and requires creative problem-solving from the engineering team.
When Not to Use a User Story
Trying to force everything into a user story format is a common Agile trap. Avoid using them for:
- Pure Technical Debt or Infrastructure: Upgrading a database server or migrating to a new API protocol doesn’t have an end-user persona. Use Technical Tasks or Spikes instead.
- Bug Fixes: A bug is a failure of existing functionality. These should go through your ticket system as usual.
- Strict Waterfall/Fixed-Price Compliance Projects: Some projects are best left in specification documents
The Hierarchy: Business Case vs. BRD vs. User Stories
In larger business at least, a user story does not replace your business case nor business requirements document; it inherits from them. Here is how they fit together:
| Document Type | The Core Question |
|---|---|
| Business Case | Why are we spending money? What will we gain? |
| Business Requirements Document (BRD) | What business capabilities do we need? (in order to realise the benefits outlined in the business case) |
| User Story | How does the user interact to fulfill that need? |
It is not a 1:1 relationship between any of the above. One business requirement could be zero, one or many user stories. And one user story could relate to one or more business requirements.
How to Write a User Story: The Discovery Process
Writing a user story isn’t about sitting alone and typing madly into JIRA. It is a problem-solving process:
- Understand the user need: Conduct user research (using our latest solution, Jessica), look at data, and speak with users, or SMEs who deal with actual customers to understand motivations and pain points.
- Define the Core Problem: What is stopping the user from achieving their goal right now?
- Collaborate (The 3 Cs): Bring the architect/designer and the engineer/developer together. Discuss how to solve the problem efficiently.
- Draft the Scope: Focus purely on the smallest slice of functionality that solves the immediate problem.
How to Format a User Story
The standard template frames the requirement around identity, action, and motivation:
As a [Type of User]
I want to [Perform an Action / Use a Feature]
So that [I Can Achieve a Specific Benefit or Value]
Let’s do an example for an imaginary new “ride share” app:
As a new user
I want to see how far away my driver is from me
So that I know I have an action to be taken and do not miss a message
JIRA can be a disadvantage here. When I first started writing user stories, we would write them on index cards and stick them on the wall. The front was the user story and the rear was the acceptance criteria.
There is something about working in the physical medium that makes the process a lot more stringent. If something is missing, it really stood out. We would turn around and ask for input from others on the team. Some people have only ever used JIRA so it is a lot easier for them to just type away all by themselves and go.
What to Include with the user story
This is the biggest differentiator we see with how people write user stories. Most people are familiar with “As A, I want, So that” but there doesn’t seem to be a 100% shared approach with what else to include..
Some businesses bought JIRA licences, implemented daily stand-ups and left it at that. There are definitely teams out there who simply type the above user story syntax into JIRA and consider the user story to be all good.
Some other businesses are fully agile and implemented more detailed templates. But over time, as people come and go, the templates being used evolve to match that businesses culture. Good or bad.
What I am listing here is neither the right way, nor the wrong way. But it is the way I have formulated the user story documentation in all client engagements. Not that I go in and only use this method. The team I am on will always workshop our ways of working, which includes the user story template, the ‘definition of ready’ (the criteria that must be true before the user story can be picked up in sprint planning) and the definition of done’ (the criteria that must be true for the team to claim success).
- Context: The “backstory.” Why are we building this? What user feedback or strategic shift triggered this item? This is your introduction for the reader
- The User Story: The standard As a… I want to… So that… framework
- Plain English Explanation: A short, jargon-free summary of what the feature actually is. No acronyms. No system names without explaining what they do. If a non-technical stakeholder reads this, they should immediately get it
- In Scope: Lists what the team will build for this user story
- Out of Scope: Explicitly lists what will not be built right now (it is useful to include reasoning for any contentious scope exclusions)
- Related Business Goal: Links the story back to the broader company strategy (e.g., “Increase user retention”)
- Related Business Requirements: Direct cross-reference to the parent requirement in the BRD
- Current Process: A breakdown of how the user handles this task today
- Target Process: A step-by-step view of how the workflow will look once this story goes live
- Acceptance Criteria: The hard boundaries and rules of the story
- Test Scenarios: Core pathways, edge cases, and error states the testers need to validate before marking the story as done
- Any Other Notes: Technical constraints, mock-ups, dependencies on other teams, common points of confusion
I like to create and include visuals and diagrams for any of the above sections if I feel it will help “double-explain” something and reduce the risk of misunderstandings later.
A note about acceptance criteria
I do these in one of two ways:
The first way is like a book.
As each user story is end-to-end, I turn the process in to section headers and add bullet points for each section. So for our ride share example I would have sections such as “booking the ride”, “waiting for the driver” and also including things that happen as outputs of the process, like “reporting”, “logging” etc.
The second way involves writing acceptance criteria in the Given → When -> Then format. Like this:
Given I have booked a ride
When I look on the app’s home screen
I can see how far away the driver is, in kilometres
Estimation Part 1: Assigning Business Value
Once we have a number of user stories, at some point we will have to pick them up for delivery. How do we decide which ones to do?
We will do a two week delivery sprint to deliver a certain volume of effort. Not all user stories are created equal and some will take longer than others (due to the effort involved). So we assign a unit of value to indicate the effort involved. But before this, the product owner must assess value. Common frameworks include:
- Value Mapping: Scoring the story from Low to High, or a numerical scale, based on customer impact or benefits to be realised
- MoSCoW Method: Classifying stories as Must have, Should have, Could have, or Won’t have
- WSJF (Weighted Shortest Job First): A calculation that prioritises items that deliver the highest value combined with the shortest duration, minimising the Cost of Delay.
I find that most places just do one of the above methods (MoSCoW or a simpler version of just MUST HAVE and NICE TO HAVE is the most common method) but it can be more beneficial to do both MoSCoW and Value mapping because at some point you will need to choose between two MUST HAVE user stories.
Estimation Part 2: Relative Sizing
Now we know how important the user stories are. It is almost time for the team to go into sprint planning and commit to their work for the sprint. When it comes to delivery effort we use Relative Sizing.
Teams use the Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21…) to assign Story Points.
- A 1-point story is trivial (like changing a button colour)
- A 5-point story has moderate complexity
- An 8 or 13-point story introduces high uncertainty and complexity
Why Fibonacci? Because as a task gets larger, our ability to estimate accurately shrinks. The gap between 5 and 8 reflects that uncertainty far better than guessing the difference between 15 and 16 hours.
When a story is estimated at 13, it is a sign that it is time to split it further in to smaller pieces.
Using construction as an analogy is my favourite way to think about this. The examples are not perfectly scaled but hopefully you get the idea (number 1 is a tent by the way).
Prioritising User Stories
Once you have Business Value and Effort (Story Points), you can prioritise your backlog effectively. You want to look for the sweet spot: High Business Value + Low Effort = Quick Wins.
The Dos and Don’ts of User Stories
| Do | Don’t |
| Do involve the whole team in the creation process | Don’t put the solution in the “As a, I want, So that” |
| Do keep stories small enough to be completed within a single iteration/sprint | Don’t write stories that drag on for weeks. This will destroy your stand-up |
| Do follow the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) | Don’t write stories which are incomplete pieces of functionality. Always think of it like this “if the team shut down immediately after finishing this, could we deploy this to users?” |