Gallery
Object Oriented Analysis & Design with UML
Share
Explore
Gallery
Object Oriented Analysis & Design with UML
Learn Agile & Scrum

12-Write Effective User Stories

Write Effective User Stories

⁠
Loading…
⁠
⁠
💡 Special Note - The following chapters around user stories, acceptance tests, the definition of done (DoD), and getting started with Scrum will offer many different definitions and suggestions. These are examples, options, and possible solutions. Scrum doesn’t define “how” to do these things or even that they must be done except for the DoD. How you and your organization choose to create Product Backlog Items, express testing needs, and use Scrum is acceptable and within the boundaries of the Scrum Guide. Please review the Increment section of the Scrum Guide to understand the minimum criteria around the DoD and how it relates to the Increment.
Understanding agile documentation is a crucial part of working in an agile environment.

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.
⁠
image.png
⁠
⁠
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:
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.
⁠
image.png
⁠
⁠
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:
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!)
⁠
image.jpeg
⁠
⁠
User stories encourage conversation and prompt "what if" questions
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.
⁠
image.png
⁠
⁠
Characteristics of good user stories
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.
You don't need exact estimates, but you need some relative ones so the product manager can prioritize the user story. For example, when using a relative estimate, you can explain that user story #1 is twice as big as user story # 2 without saying how long it would take to do either.
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.
⁠
image.png
⁠
⁠
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.
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.
This is just a sample of the possible user stories. In fact, some could be epics (e.g., pay for the event) and be broken down further!
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)?
These are good questions to ask after you have written a user story, but before you start working on it!
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.
These are good questions to ask after you have finished a user story!
Additional Resources • User stories are a popular agile technique to capture product functionality. Working with user stories is easy, but telling compelling stories can be hard. This article will provide you with
10 Tips
⁠
for writing good user stories. • Sometimes user stories can be ineffective and do not provide an accurate view. This impedes agility. The following article illustrates how to improve user stories:
Fixing bad user stories
⁠
.

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!
Gallery
Share
 
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.