• 10 hours
  • Medium

Free online content available in this course.



Got it!

Last updated on 5/19/20

Write Effective User Stories

Log in or subscribe for free to enjoy all this course has to offer!

What are user stories?

User stories are short descriptions of a product enhancement (i.e. a product feature) expressed in the following format:

As a < type of user >, I want < some goal > so that < some reason >

User stories should be expressed in this format
User stories should be expressed in this format

Examples of User Stories

The best way to understand what user stories are is to look at some examples. Have a look at the examples that I have created below.

  • As a blogger, I want to show a Twitter share button at the end of each blog page so that my readers can share this article in their Twitter feed with one click if they want to.

  • As a snapchat user, I want to be notified if another user who receives my chats takes a screenshot so that I can know if all traces of my message have not been deleted.

  • As a Facebook Group Organizer, I want to see the behavior of my community members so that I can see which of my promotions are working.

  • As a marketing manager, I want to apply free delivery to all shoes listed on our website for a specified period so that I can run promotions.

  • As an OpenClassrooms teacher, I want to create a quiz so that students can be evaluated on their knowledge of a course they are doing.

User Stories are Simplified Requirements

User stories are simplified versions of real requirements.  Let's take one of our user stories above:

As a blogger, I want to show a Twitter share button at the end of each blog page so that my readers can share this article in their Twitter feed with one click if they want to.

A user story
A user story for a twitter share button

If you show this user story to your engineering team in a planning session, they will probably ask questions like:

  • If the reader is logged-in to Twitter, then do we expect that the message posts directly?

  • If the reader is not logged-in to Twitter, what should happen?

  • Can a reader post this link on their Twitter feed more than once? Is there a limit?

  • What if the URL to the blog post is greater than the Twitter character limit? 

  • Do you need to track how many people click on this link? Should we use a link management tool like http://bit.ly

  • What should happen if the Twitter service is down? (god forbid :waw:)

A short user story encourages conversation and
User stories encourage conversation and prompt "what if" questions

You can see that the engineering team asked a lot of relevant "what if" questions!  This information (the answer to all these questions) is not contained within the actual user story itself. This is good news because:

  1. It forces the whole team to have a conversation about the user story. 

  2. The user story is expressed from the perspective of the user. By understanding the user's goal, we can investigate whether the feature suggested is the best way of helping them achieve that goal! Sometimes the engineering team thinks of an idea that is better than what is written on the card.

  3. Writing short descriptions like this in non-technical language means that the whole business (not just tech people) can understand what the team is working on. 

  4. As a team, it is easy to handle new requests; put a user story on an index card (or post-it note) and add it to the user stories wall in your office . Once it's time to work on it, we'll figure out the details (i.e. we can answer all the 'what if' questions just before we start work).

The Invest Model

Agile consultant and author Bill Wake describes the characteristics of good user stories by using the INVEST model.

Characteristics of good user stories
Characteristics of good user stories

Independent - When user stories are independent, they do not overlap each other in functionality. Thus we can begin work on a user story in any order we choose, because there is no dependency on any other user story.

Negotiable - Part of the beauty of the user story is that it reveals a need and why it is needed. As Bill Wake says "A good story captures the essence, not the details".  The details will be ironed out later by stakeholders and developers just before and during development.

Valuable - The user story must be valuable as perceived by the customer. This should lead the development team to try to deliver value per user story that the customer can see (not just work on the database layer for example that is not a layer that they customer can see).

Estimable - When discussing a user story, if the team says they cannot estimate the work required for the user story because information is missing, then we need more information (as part of our negotiation!) before we can begin. 

Small - Good user stories are small and typically can be done in a few days or weeks by a developer. When user stories are bigger than this, then we have an opportunity to split them. 

Testable - If the team doesn't know how to test a user story, then they probably don't understand what is being asked for. Knowing exactly what to test is equivalent to knowing exactly what to build.


An epic is just a big user story. We manage epics by breaking them down or "splitting" them into several user stories.

Epics break down into user stories
Epics break down into user stories

Consider the following user story:

As a group organizer, I want to schedule events for my members so that I can encourage them to attend upcoming events.

In reality, this may break down into a set of user stories like this:

  • As a group organizer, I want to create an event in the system so that I can promote my real-life events.

  • As a group organizer, I want to see a list of created events so that I can manage events.

  • As a group organizer, I want to be able to pause an event so that invitations are no longer sent.

  • As a group organizer, I want to be able to cancel an event so that any people who registered get notified of the cancellation.

  • As a group organizer, I want to choose an audience that the event is sent to so that I can target my events to the right people.

  • As a member, I want to receive an email for events so that I am aware when I am invited to one.

  • As a member, I want to receive an in-app notification so that I am aware when I am invited to an event.

  • As a member, I would like to RSVP for an event so that I am guaranteed a place at the event.

  • As a member, I would like to pay for the event in advance with a credit card.

In summary:

  1. Large user stories are called epics

  2. We treat epics by decomposing them (or splitting them) into individual user stories

  3. We split them before working on them, but not too long before. There is no point spending time on decomposing epics that are low priority. 

Improving your User Stories

AgileKRC shares the following Big Three Questions that you (or your team) can ask after creating user stories:

  1. Immediately after reading the User Story, is it obvious what the User Story is about?

  2. Does each element of the User Story add significant value and therefore avoid duplication or partial duplication of other elements?

  3. Is it totally 100% free of ‘the how’ (the solution)?

Agile consultant Ben Linders adapts the "Perfection Game" pattern from the book 'Software in Your Head' as a good way to learn about how to improve user stories after the team has worked on them. If you are organizing a 'lessons learned' meeting (often called a 'retrospective' meeting), you could take user stories that have been completed and get some members of the team to:

  1. Rate the User Story … (a score between 1 and 10)

  2. Explain what they liked about the User Story

  3. Explain what they would do to make it perfect

Additional Resources

10 Tips for writing good user stories

Fixing bad user stories 

Example of certificate of achievement
Example of certificate of achievement