User Stories are the oil in the Agile engine. They make or break success for projects delivered with Agile methods, in short – bad user stories = bad project outcomes.

Writing good user stories, and managing them correctly throughout the project, is therefore an essential skill in any Agile team.

What is a user story?

Broadly, we can say that a user story is how requirements are captured in an Agile project. A user story is a short description of a requirement, written as if it was explained by the user that wants it.

It should be written in simple, brief language, but include three key sections:

what is a user story

As a [type of user]: this should be a brief descriptor that tells the team who needs the requirement. This information is important because ____ 

I want [some goal]: this should be a clear description of what the requirement is. This is probably the simplest part of the user story, and it is fairly similar to a requirements statement in a traditional project.  

And finally, here comes the really important bit… 

So that [some reason]: here there must be a clear statement that explains what it is the user should be able to do once their requirement has been met

Where and how do I document or store my user stories? 

Agile rests on a few key principles, including that we should keep documentation to a minimum and everyone in the project should have insight into what we are working on – so visibility and transparency is key. (Note; this was an abbreviated and paraphrased summary of the Agile principles).  

Therefore we want to avoid lengthy documents that are saved behind lock and key. Instead we want to keep our collection of user stories light, easy to manoeuvre and visible to everyone.  

A good way of doing this is to write down each user story on its own separate piece of paper, or card (or virtual equivalent). In fact, you will often here user stories referred to as “cards” for this reason.  

The user stories (cards) are then placed on a big board, or wall (or virtual equivalent) which we call a Backlog.   

The Backlog is the one and only storage place for user stories for our project.

What should each card contain?

Each card should be self contained, meaning it should contain all the information you need to understand what the user story is.  

Typically this would involve: 

  • The story description (As a… I want… So that…) 
  • The story priority 
  • The effort estimation 

Also useful information is: 

  • If the story is part of a grouping or category (called a Theme or Epic) 
  • Description of business value 
  • Risks associated with the story 

A user story card may look like this: 

user story card

How do I know if my user stories are good enough?  

It is not often a project professional can say “aha, I have a formula for this” but on this occasion we can! The INVEST formula is a handy tool to check the quality of them. 

It works like this:  

Do you want to learn more about how to create, estimate and manage user stories? Check out our APM accredited Agile Project Management course!

On This Page

Monthly Newsletter

By: Karin Maule

Karin Maule
Categories: Project Management

Published: 26 October 2022

Book onto an Event