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;
- 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
- The stories are being managed digitally and the focus is all on how many you have to complete and by when
- All the stories are created at the start of the project and are placed into a contract
- The team are asked to work overtime to complete all the stories in the sprint as that the team estimated at the start
- The stories are written in silo, so not linked to real user data (customer conversations, testing, data etc..)
The INVEST APPROACH
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.
