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.

Wikipedia states:

“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.