• 10 hours
  • Medium

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 11/9/21

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 >

An index card that reads: a type of user , I want some goal , so that some reason
User stories should be expressed in this format

For this class, we’ll express user stories in this format. However, there are many different ones. The format you use in the future will depend on your organization and how it wants to express needs from a customer’s perspective.

It doesn’t mean that one is wrong and one is right, just that as someone working with different products, you need to keep the value for the customer in mind.

Examples of User Stories

The best way to understand what user stories are is to look at some examples:

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

Recognize User Stories as Simplified Requirements

User stories are simplified versions of real requirements. Let's take one from 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.

An index card that reads: 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 for a Twitter share button

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

  • 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? :waw:

A photo of a note pad surrounded by the questions who what when where why and how
User stories encourage conversation, and prompt "what if" questions, and indicate who you are creating this value for (i.e. the customer, persona or user type). 

You can see that the engineering team asked a lot of relevant "what if" questions! Unfortunately, this information (the answers) is not within the actual user story itself, which 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, you can investigate whether the suggested feature is the best way to help them achieve it! Sometimes the engineering team thinks of an idea that is better than what is on the card.

  3. Writing short descriptions 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 sticky note) and add it to the user stories wall in your office. Once it's time to work on it, you'll figure out the details (i.e., answer the questions just before starting work).

Identify the Elements of the INVEST Model

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

An image of the INVEST model that shows what each letter of the word stands for. It is also in the text below the picture.
INVEST is a good reminder of things to consider in a user story

Independent - When user stories are independent, they do not overlap in functionality. Therefore, you can work on them in any order 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 stakeholders and developers will go over the details later just before and during development.

Valuable - The user story must be valuable to the customer. This should lead the development team to try to deliver value that the customer can see (not just work on the database layer that they can't see).

Estimable - If the team says they cannot estimate the work required for a user story because information is missing, then you need more (as part of your negotiation!) before you 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 more extensive, you can split them. 

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

Define the Role of Epics

An epic is considered a really big user story. You manage them and other large items by breaking them down or splitting them into several user stories.

An index card labeled epic that reads: as type of user , I want some goal , so that some reason followed by an arrow labeled breaks down into leads to many index cards labeled user stories that read: a type of user , I want some goal , so that some reason

 A large epic broken into multiple 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.

A Final Note on Epics

  1. Large user stories are sometimes called epics.

  2. You usually start by deconstructing a large work item into smaller individual ones called refinement. Then, the team will determine the right size for them through experience. 

  3. You want to split large items before working on them, but not too long before as that may waste time and effort. 

Improve Your User Stories

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

  1. Is it obvious what the user story is about immediate after reading it?

  2. Does each element of the user story add significant value and avoid duplicating (or partial duplicating) other elements?

  3. Is it 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. You can check out his website here and the book here. If you are organizing a lessons learned meeting (often called a retrospective meeting), you could take completed user stories 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 it.

  3. Discuss what they felt was lacking.

  4. Discuss how they tested it and how they could have eliminated any mistakes found later when it was being written.

  5. Explain what they would do to make it perfect.

Let’s Recap!

  • User stories are just one specific type of Product Backlog Item.

  • Many organizations call a large user story an epic, which will most likely need to be broken down into smaller, more targeted user stories.

  • There are many ways to break down large items like epics. A popular method is to keep the persona or actual customer in mind and create different user stories for different types of customers.

  • Keeping the principles of INVEST in mind when creating user stories may help you as you learn what makes up a good user story.

Now that you know what a user story is, let’s take a look at an in-depth example of the process in the next chapter! 

Additional Resources

Example of certificate of achievement
Example of certificate of achievement