• 15 hours
  • Easy

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 10/15/19

Write Effective User Stories

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

Understanding Agile documentation is an important part of being able to work in an Agile environment.

If you've already taken the Write Agile Documentation course, you can skip to the fourth chapter "Get started with Scrum."

What are User Stories?

Requirements in SCRUM are captured using 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 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 takes a screenshot of my chat so that I can know if my message has 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 taking.
     

User Stories are Simplified Requirements

User stories are simplified versions of real requirements.  Let's take one of the 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 for a twitter share button
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!)

User stories encourage conversation and prompt
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, you 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.
    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. 

  3. 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. You'll figure out the details once you're ready to work on it (i.e., you can answer all the "what if" questions just before you start work).

  4. In the above scenario, where a product manager chooses a user story and then discusses it with the engineering team in a planning session (often called a Requirements Workshop), is perfectly normal. After a healthy discussion, more details are known and written down. This allows the team to define a set of scenarios known as acceptance tests, which represent the details of the user story. 

  5. User stories may be written by various stakeholders including clients, users, managers, or development team members. Most commonly, it will be the product manager who writes them.
     

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 you can begin work on a user story in any order you 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 a visible value for each user story (not a database layer which is not something the customer can see).

Estimable - When discussing a user story, if the team says it cannot estimate the work required for the user story due to missing information, then you need more information. 

Small - Good user stories are small and typically can be completed in a few days or weeks by a developer. When user stories are bigger, you may be able to split them. 

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

Epics

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 a targeted audience the event is sent to so that I can cater my events to the right people.

  • As a member, I want to receive an email for events so that I can be alerted to invitations. 

  • As a member, I want to receive an in-app invitation notification so that I am aware of upcoming events.

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

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

In summary:

  • Large user stories are called epics.

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

  • We split them before working on them, but not too long before. There is no point spending time on breaking down 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

Summary

  • Requirements in SCRUM are captured using 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, if written well, should be independent, negotiable, valuable, estimable, small, and  testable.

  • Large user stories are called epics and should be broken down into smaller user stories.

Additional Resources

Example of certificate of achievement
Example of certificate of achievement