What is a user story? (ELI5)
TL;DR — A user story is a short description of functionality told from the user’s perspective.
Previously we spoke about agile methodologies from a non technical perspective, using more accessible terminology, and through the power of dank memes. This article is following a similar vein, but talking more specifically about user stories.
“In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system.”
As in the TL;DR user stories are high level, and succinct definitions to outline a piece of functionality or a feature.
So a REALLY basic example:
“As a user, I want something to happen, so that some reason”
The story should be from the viewpoint of the user, not yourself (a developer, project manager, etc).
It should describe the feature, event, or piece of functionality in simple language.
You should finish it with a reason for the story, eg the value it creates, or the purpose of the feature to the business.
What is an epic?
TL;DR — An epic is a super story, and the parent of multiple child user stories
Sometimes user stories can be big and complex. This creates a story that is too vague / generalised, and a single story won’t do it justice. When this happens, it’s generally best as an epic, (a super story).
Try to think of an epic as a compilation of user stories. That makes a user story something that describes a single piece of functionality, not a collection. This epic can then be broken down into the individual child user story components.
Also if using Scrum, and something is too big to fit into a sprint, or the number of story points is high, this is a good time to make it into an epic and break it down further.
An epic can also be defined without user stories, as something that needs to be specified in more detail later.
Why use user stories? Why not just a task?
TL;DR — A user story is the WHAT, the task is the HOW.
Without an agile background it’s easy to confuse a user story and a task. There is a fairly simple distinction. Tasks are individual pieces of work, user stories describe a piece of functionality from the point of view of the user.
Typically the user story is created by the product owner, or by whoever is carrying out any high level planning. Each user story is usually broken down into tasks created by production (developers, QA, etc).
You would use a story over a task when you are discussing overall features, not the specific way you would implement it.
What are acceptance criteria?
TL;DR — Defining conditions for when a user story is done
Acceptance criteria, also referred to as ‘conditions of satisfaction’ are used to confirm when a story is complete. When the story is working as intended, with various criteria satisfied, it can be marked as done.
They are important as they help the team to test, clarify potentially vague stories, and to prevent stories getting over engineered.
Edit: Thanks to /u/slow_cars_fast on reddit for pointing out this is not quite the same as ‘Definition of Done’.
Acceptance criteria is, “did we build the right thing”. Definition of Done is “are we finished building the right thing?”
How to write good user stories
TL;DR — Short, clear language, who is it for, and why do you need it?
- Keep them short
- Use simple language
- Perspective. Who is the story for? (user, admin, etc)
- Why? What is the reason for the story? (what value or benefit does it bring)
- Describe a single piece of functionality / scenario
- Collaborate, write stories together
- Use epics to group larger collections
- Use acceptance criteria to know when it’s done
User story examples
TL;DR — Who? > What? > Why?
As a naked person, I want to put on clothes, so that I stay warm.
- Acceptance
- I am wearing 1 pair of boxers (or briefs / other, your choice)
- Both legs are protruding from the correct holes
- Boxers are on my waist
- I don’t have a wedgie
As a shopper, I want to add an item to my cart, so that I can purchase it
- Acceptance
- Clicking on the BUY button triggers an event
- The event adds, or increments that item in my cart
- The correct item is added
As an admin, I can create other admins, so that I can delegate tasks
- Acceptance
- I can see a list of users
- Pressing the MAKE ADMIN button gives me a confirmation
- Agreeing to the confirmation gives that user admin rights
- Cancelling the confirmation takes me back to the list
Conclusion
A user story is a clear and concise description of a single piece of functionality from the perspective of the user. It should include reasoning for the functionality to exist and should be able to complete within a single sprint (or broken down into smaller stories).
User stories allow (perhaps non technical) product owners to outline a set of requirements without getting into too much technical detail. User stories discuss features, and possible impacts on effort using story points (which will be covered in our next article). The production team can later define related technical / implementation tasks independently.
Thanks for reading the Scrumi.io blog! Make sure you give this post your 👏 50 claps 👏 and take a minute to follow us on here and on Twitter if you enjoyed this post and want to see more.
Note / standard ELI5 disclaimer: A lot of the above is generalising, and misses some in depth elements of user stories. That’s fine, there are thousands of lengthy and complex articles discussing these practises in great (usually too great) detail. Google is your friend :)
