What Are User Stories?
Requirements in Scrum are captured using user stories, which 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 >
A very common practice is to write user stories on an index card (like the image below) and then put them on a wall in the office.
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 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 to evaluate students 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 my readers can share this article in their Twitter feed with one click.
If you show this user story to your engineering team in a planning session, they will probably ask questions like:
Will the message post directly if the reader is logged-in to Twitter?
What happens if the reader is not logged-in to Twitter?
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 happens if the Twitter service is down? (God forbid!)
You can see that the engineering team asked a lot of relevant questions! Unfortunately, this information (the answer to all these questions) is not in the actual user story, which is good news because:
It forces the team to have a conversation about the user story.
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 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.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 before you start work).
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 normal. After a 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.
Various stakeholders may write user stories, 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.
Independent - When user stories are independent, they do not overlap in functionality. Thus you can begin work on a user story in any order you choose because they are dependent on another user story.
Negotiable - Part of the beauty of the user story is that it reveals a need and why. As Bill Wake says, "A good story captures the essence, not the details." The details will be ironed out later by stakeholders and developers before and during development.
Valuable - The customer must perceive the user story as valuable. It should lead the development team to deliver a visible value for each user story (not a database layer that is not something the customer can see).
Estimable - If the team can't estimate the required work due to missing information, you need more information.
Small - Good user stories are small and 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, they probably don't understand what they need. Knowing what to test is equivalent to knowing what to build.
Epics
An epic is a big user story that you manage by breaking them down or splitting them into several 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.
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.
Treat epics by deconstructing (or splitting) them into individual user stories.
Split them before working on them, but not too long before. There is no point in spending time breaking down epics that are low priority.
Improving Your User Stories
It is critical that you get accurate user stories. In this article, agileKRC shares their perceived Big Three Questions that you (or your team) can ask after creating user stories:
Immediately after reading the user story, is it obvious what the user story is about?
Does each element of the user story add significant value and therefore avoid duplication or partial duplication of other elements?
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 how to improve user stories after the team has worked on them. In this article Ben Linders offers guidance if you are organizing a lessons learned meeting (often called a retrospective meeting), you could take finished user stories and get some members of the team to:
Rate the user story (a score between 1 and 10).
Explain what they liked about the user story.
Explain what they would do to make it perfect.
Let’s Recap!
Capture Scrum requirements through 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.
Break down large user stories (epics) into smaller ones.
Now that you know all about User Stories, let's discover what we call in Scrum the Acceptance Tests!
