Agile Delivery

What is a User Story?

October 31, 2020
8 mins read
Ben Willmott

An introduction to User Stories

The user story approach was created in the late 90’s after Alistair Cockburn coined the phrase “A user story is a promise for conversation whilst visiting the Chrysler factory in Detroit. 

Then were then used in Extreme Programming (XP) as part of the planning game around this time, so they’ve been around for a while now.

They really took off when Mike Cohn wrote the book titled User Stories Applied: For Agile Software Development which is still just as relevant today.

In these early days a user story was used as it they should be, so an informal description of the user need rather than a requirement.

User stories, more often than not are misunderstood and are taken as requirements in software development, when they’re actually just a description of a feature and a user need. I’ll go into this in a bit more detail further into this post. 

A user story gets its name from how it should be used, not how it should be written. A story should be told in a natural way through a good conversation.

A good story conversation is about the who, why and not the what. 

Discussing the why and who it’s for, creates a greater focus on the real need of the users versus when you’re discussing a requirement, you talking about what you’ll do and how long it will take. 

Focusing more on the outcome over the output is much more important, as ultimately this is where the value lies

A user story is typically written like the below. You can see how this format aligns with focusing on who this is for (the user), what they need to achieve (the goal) and then the outcome (a reason)

As a < the user >, I want < a goal > so that < a reason >.

There are many variants of the above, but if you stick with this structure you can’t go too far wrong.

What is a good user story?

Although there are countless examples of how to write user stories, what makes a good story is really what you do with it.

It’s not about how well written it is, it’s about the value it creates. 

A story is really only as good as the team who are working with it.

By that I mean if the team are using the story as it should be used, then ultimately it’s a good user story. So are they describing the user story as a story through conversation?

This could include not only discussing the story, but also collaboratively looking into how they could create it through sketching out the solution.  

Stories are discussions about solving problems for the clients organisation, customers and its users. 

One way you can describe a story as being ‘good’, is if it provides value to the end-users. If it’s not providing value, then it probably shouldn’t be worked on or used. 

Not to contradict the above, but you never truly know what the user will need and what will be a success, so you can’t only place value on the end-user outcome. 

Sometimes a story created for the customer will fail miserably, but the team have learnt some really important lessons which eventually will allow them to create even greater value for the user, or just become a better team from it.

So learning through failure is really important, every team should be prepared to fail.

A good story could also be measured in the amount of conversation and linked ideas it generates.

I’m not saying you should try and measure this, but the point is the more conversation generated the better, as long as the end-user value is always front of mind.

User stories are not requirements, they are a story of what the user needs. 

Traditional requirements tend to stop the conversation as they say here are the requirements, now you go design or build it. At this stage, it’s it doesn’t matter how, just the what! 

With this approach, you’re missing the opportunity to really question the why, but it’s easy to fall into this trap.

You can be working with user stories and still work in this way, so look out for when user stories turn into requirements, a few indications of this are;

  1. The Product Owner or one person creates all the user stories themselves and are passed on as this is what you work on next no questions asked
  2. The stories are being managed digitally and the focus is all on how many you have to complete and by when
  3. All the stories are created at the start of the project and are placed into a contract 
  4. The team are asked to work overtime to complete all the stories in the sprint as that the team estimated at the start
  5. The stories are written in silo, so not linked to real user data (customer conversations, testing, data etc..)


To help with working out what is a good user story, you can use the INVEST approach that describes the qualities of a good user story:

  • Independent
  • Negotiable
  • Valuable to user or business
  • Estimable
  • Small
  • Testable

Independent: The story stands alone. Stories that are highly dependent on each other are hard to prioritise (“all the stories are equally important”) and hard to estimate (“I can’t put a time on that until we’ve finished that other story”).

Problems with dependencies can be solved by dividing stories differently or combining several small stories into a single larger one.

Negotiable: A story should be the starting point for a conversation and an opening for the team to suggest a solution, not a detailed description of how the Product Owner expects that feature or piece of functionality to be implemented.

Valuable: It’s all about the end-user. If you can’t describe the value a customer is going to get out of your story, it’s not a good story.

Estimable: No estimate, no entry into the sprint backlog. If there’s not enough information or definition to allow the team to put an estimate on a story, it doesn’t get started.

Small: A story shouldn’t take longer than a sprint to finish. Any larger than this and it’s hard to estimate or plan for. It’s also likely to be hard to write acceptance criteria and to test.

Testable: If you can’t test it, how do you know when a story’s done and working as it should?

When is a story done?

When it comes to creating a product and working on a user story, it’s only done when it meets all of the acceptance criteria, or when working within the Scrum Framework, the Product Owner has accepted it as done. 

Creating acceptance criteria is really important as the story itself is there to drive value and understand the user needs, but the acceptance criteria are there to make sure the product itself meets certain requirements. 

For example, there is no point creating a great new feature in-app for your users, if it doesn’t work on the devices they users actually use. Or the feature created isn't inline with the client brand or tone of voice. 

The acceptance criteria also give the team the structure to be able to test what they have created. If you only check that the user story is fulfilled, so using the example below.

The feature update is built and the team have seen it working, you could say that story is done.

However, if it doesn’t update then reflect this change on the homepage of the app, or it only works in the app version, not the web version, then the story isn’t truly done

As a user, I want to be able to add my nickname in the settings so that easily see which payment card I’m using

So, in summary, the acceptance criteria can be quality checks, tests, defines the boundaries of the story so it isn’t too broad and also help the team to plan and estimate the story. 

How to split a user story

When user stories are created, it’s hard to know when to split them, or even if they should be split at all.

The most common reason to split a story is because it’s either  to big (takes too long to complete) or it’s very complex and becomes a mini project in itself, to work out how you’ll complete it.

Ideally when it comes to completing the user stories, you want them smaller enough that the team can estimate them with reasonable confidence, understand how they build it and also complete it in a short enough time so you can then get it in the customers or clients hands for feedback. 

That last point is really important as getting feedback early is critical, as you would rather learn and fails in small fast increments over one big bang and then fail! 

There are many approaches to splitting user stories but the SPIDR approach is one of my favourites

Spike = only try after trying the other four, time box an investigation into a specific problem to help the team understand the problem better. Then hopefully you can then write a story or stories that are achievable

Paths = Think of the paths through the story and split the story into these. Draw out the flow chart to help with this. This doesn't mean you should split every path within a story. Or you can also split a single step, a confirm order story for example

Interfaces = Split the stories into browsers, iOS, Android etc...So you could actually split by browsers if one is particularly complex from a design or engineering perspective,

Data = simplify the data, so rather than far-ranging requirements, like what is the best date to release a new movie, change to what is the best data for a certain type of movie or vs release dates of other movies. 

Rules = Some stories are large because of the rules they need to comply with. Relax the rules so you can show work and get feedback earlier. 

So that’s a user story. If you want to learn more about Scrum then take a look the Introduction to Scrum post.

Ben Willmott
Ben is Head of Agile Practices at the London based creative agency Karmarama where he creates bespoke ways or working for his clients and teams. Ben is also the founder of The PPM Academy specializing in coaching Project Management, Agile Delivery and how to be more productive at home and work.

More Blog Posts

Project Management

Dealing With Change as a Project Manager

Change is going to happen whether you’re working with the Waterfall approach, Agile or any other delivery methodology. It just comes in different forms. But change shouldn’t be seen as a negative; change is about improvements, doing what’s right and what’s needed for the business and its users.

Read Article
Agile Delivery

An Introduction into Story Points

Story Points are often misunderstood and misused by teams and in some cases render them useless. In this post, we look at how you can educate the team on what Story Points are and how to use them.

Read Article
Agile Delivery

Waterfall vs Agile: What to Choose?

The Waterfall methodology or model is the traditional approach to project management. It breaks down the stages of a project into sequential phases.

Read Article

Register your interest in the PPM Course for early offers and updates