User Stories: What are they? Why use them?


Story Time with the Fam

Everybody loves a good story.

Stories are powerful tools.

They help us remember, they entertain us and they allow us to relate to one another unlike anything else.

If you’re familiar with Agile development (if not, start here) you’re probably aware that user stories are a common approach for capturing product requirements. But have you ever wondered, why?
Or have you ever been curious about where they originated?

If so, this article might be able to help.

Key Takeaways

What is a user story? 

A user story is a lightweight method for quickly capturing the “who”, “what” and “why” of a product requirement.

User stories are written in everyday language and describe a specific goal (the “what”) from the perspective of an individual (the “who”) desiring that goal along with the reason (the “why”) he/she wants it.

In software development, the goal is often a new product feature, the individual is some type of end-user and the reason is the benefit that user sees in the said product feature.

Why use user stories? 

User stories complement Agile principles by emphasizing customer-centric conversations reducing the time spent writing extensive documentation allowing teams to more quickly deliver quality software that customers want.

The simple and consistent format saves time when capturing and prioritizing requirements while remaining versatile enough to be used on large and small features alike.

Some Background

User stories first emerged onto the scene in the late 90’s as a somewhat vague concept being utilized in Extreme Programming (XP) circles for defining project scope. They were referenced as an alternative to, but “like”, the more detailed use cases often seen in product requirements documents. [3]

In the 2000’s, more guidelines and interpretations began to appear that further define how many utilize user stories today.

Connextra Story Card from 2001

Connextra Story Card from 2001 – img [4]

In 2001, a team at Connextra introduced the role-feature-benefit template establishing a consistent naming convention and Ron Jeffries defined the critical aspects of user stories with the Three C’s model.

A few years later, Bill Wake established the INVEST mnemonic as a checklist for quality, well-formed stories.

What started out as a vague concept nearly 20 years ago is now commonplace in software development shops around the world.

So, what are the common components seen in user stories today?

User Story Components

A user story deemed “Ready for Development” should at a minimum have the following three components: (1) a Narrative, (2) a Conversation and (3) Acceptance Criteria

1. Narrative

Each user story begins with a simple narrative that defines the user story.

The narrative typically consists of three attributes which are commonly referred to as the “who”, “what” and “why” of a product requirement*. Below are a couple of formats often seen followed by an example of each.

  • Format 1: As <type of user>, I want <some goal> so that <some benefit>
    • Example: As a user of Amazon, I want a “Buy It Now” button so that I can save time. 
  • Format 2: As a <role>, I can <action with system> so that <external benefit>
    • Example: As an Amazon Site Administrator, I can block certain users so that I can eliminate known fraudulent accounts.

Keep in mind, it is only one sentence which will undoubtedly leave room for interpretation and need more clarification later. So don’t waste too much time making the sentence overly complex or fine-tuning the wording to get it “just right”.

Save that energy for our next step: the Conversation.

2. Conversation

Once we have a simple narrative, the real work can begin to flesh out the details of the narrative through conversations among various stakeholders. This may include coders, testers, business analysts, customers and other any other individual that might be impacted.

During these discussions, assumptions will be uncovered, decisions will be made and direction will likely be clarified. The goal here is to bring clarity to the single-sentence narrative that it’s not designed to provide.

Once the narrative is sufficiently discussed and understood, it’s time to capture all you’ve learned in the next step: the Acceptance Criteria.

3. Acceptance Criteria

Assumptions or decisions generated from conversations that could impact the team’s ability to properly estimate their work should be documented here.

The team should work together to add Acceptance Criteria (or Conditions of Satisfaction**) which will be used to clarify the work that needs to be done.

While too much tweaking of the narrative can be counter-productive, it’s important for everyone to be clear on, and agree to, the Acceptance Criteria as it will be used by the Development Team to understand “what” to build and the Product Owner to confirm the work is complete.

So, how about some examples? Wow, exactly what I was thinking…

User Story Examples

The year is 1998.

You’ve assembled a development team to build eCommerce sites for local businesses and looking for your first customer. 

And what do you know? It’s your lucky day! Your Dad’s friend, Benji, owns a pet store and has recently purchased a domain to start selling his products online.

He will call it, and he wants your help to make his vision a reality.

Narrative (Example)

During your first meeting with Benji, you generate a preliminary list of 20 features that would be needed to bring this can’t-miss opportunity to life.

Below are the narratives of three of these features written from the perspective of three different roles: 1) store owner, 2) store salesperson and 3) online shopper.

  1. User Story #1
    • Narrative: As store owner, I want to see a history of all online sales so that I can forecast financials for future quarters.
  2. User Story #2
    • Narrative: As store salesperson, I want to see a list of the top-selling items so that I can know what customers are interested in.
  3. User Story #3
    • Narrative: As an online shopper, I can view details of specific products.

Conversations (Example)

After the narratives are established, the development team joins in the follow-up meeting with Benji and more detailed conversations take place.

The discussions reveal assumptions and generate decisions that need to be captured in the Acceptance Criteria to make sure everyone is clear on the work that needs to be performed.

Acceptance Criteria (Example)

Each narrative will typically have unique Acceptance Criteria that could be written in a variety of different formats.

Sticking with the narrative examples above, below are two of the commonly seen formats used for Acceptance Criteria: I can/cannot <do something> and bullet points.

  1. User Story #1
    • Narrative: As store owner, I want to see a history of all online sales so that I can forecast financials for future quarters.
    • Acceptance Criteria (bullet points)
      1. Can view by week, month, quarter and year
      2. Compatible w/ phone or laptop
      3. A button for emailing sales totals to accountant
      4. Grant/prevent access to certain individuals
  2. User Story #2
    • Narrative: As store salesperson, I want to see a list of the top-selling items so that I can know what customers are interested in.
    • Acceptance Criteria (I can/cannot…)
      1. I can view a list of top-selling items by brand.
      2. I can view a list of top-selling items for each month.
      3. I cannot accidentally delete reports when accessing them.
  3. User Story #3
    • Narrative: As an online shopper, I can view details of specific products.
    • Acceptance Criteria (I can/cannot…)
      1. I can view the name of the product
      2. I can view online reviews of the product
      3. I can view the country where the product was manufactured
    • Acceptance Criteria (bullet points)
      1. Product name
      2. Online reviews
      3. Manufacturer’s country

So, now that we know the 3 components of user stories, I’m guessing it’s time to get started on development? Well…

Not just yet. Let’s at least take a quick look at a few of the benefits of user stories first.

User Story Benefits

1. Write Less, Talk More…

I feel like Mike Cohn puts it best here:

“User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them.” [1]

Have you ever found yourself exchanging a dozen emails trying to clarify some topic only to clear it up in a 5 minute conversation? I sure have.

Situations like that remind me why Agile principles promote face-to-face communication and why conversations are such a critical component to user stories.

2. Consistent Format Saves Time

Whether it’s capturing requirements or prioritizing those requirements in the product backlog, the consistent format of user stories saves you time.

Working in new product development, it can be common for teams to capture dozens of user stories during a single brainstorming session, or for individuals to capture them periodically throughout the workday, or for some to capture them at various times while on-the-go.

A simple format that’s easy to remember reduces any time wasted thinking about how each requirement should be structured and allows anyone to easily capture and move on.

The consistent who-what-why format also saves time when prioritizing by allowing the Product Owner to quickly assess each item in the backlog, know “what” it is, “who” it benefits and “why” it benefits them.

A backlog filled with items lacking a consistent format can be a huge productivity killer when it comes time to prioritize.

3. One-Format-Fits-All

One of the nice aspects of user stories is that a single format can be used to quickly capture extremely large or extremely small product requirements, and there are advantages to both.

Sometimes you have that “big” idea that you need a placeholder for, but you’re unsure about how, or if, it can even be accomplished. Obviously, you don’t know enough, or have the time, to decompose the idea into small enough stories to be accomplished in a given sprint, and luckily, you don’t have to.

The versatility of user stories allows you to simply capture that big idea as an Epic and move on. It can be decomposed and clarified later. The fact that you can capture a large requirement quickly in the narrative of a user story is a valuable benefit over writing a long document. [1]

Now, while it’s nice to have the option of quickly capturing large chunks of functionality as Epics, the ability to decompose these ideas into smaller items is where user stories really shine.

The ability to break projects down into small stories makes it easier to plan, easier to estimate and easier to consistently deliver value to the customer throughout the development effort.

This decomposition of large features into smaller ones is what facilitates the “early and continuous delivery of valuable software” that is one of the highest priorities in Agile development. [5]

4. Empathy

Empathy can be described as “the ability to understand and share the feelings of another.” And we all could probably use a little more of it, and I think user stories can help.

When you format requirements in the first-person, it can spark the imagination allowing you to better visualize the desired functionality from another person’s point of view. [1]

And not just any other person’s point of view, the user: that individual that may ultimately determine your product’s success or failure. If there’s one person you might want to show some empathy to, this might be a worthy candidate. =)

Ok, so now we clearly understand some of the benefits of user stories, and we’ve learned that each story should have three components: 1) a Narrative, 2) a Conversation and 3) Acceptance Criteria.

So finally, can we start writing some code??? Well, not quite…

For starters, we haven’t even estimated the work, and for all we know, these stories may need to be decomposed before they can even be accomplished in a sprint.

And now that I think about it, we haven’t even talked about the INVEST (mnemonic) – something you may want to check out in order to create more well-formed stories… but we can save all that for another day.

Thanks for reading!



* Many consider the “why” optional when it is clearly implied in the narrative.

** “Conditions of Satisfaction” is a term used by Mike Cohn to avoid confusion between Acceptance “Tests” and Acceptance “Criteria”. “Acceptance criteria can be thought of as “what needs to be done” and acceptance tests (often written in Given-When-Then format) as “how they should be done”. [7]

[1] Mike Cohn “User Stories”, “Advantages of User Stories for Requirements“, “Writing Contracts for Agile Development“, “Advantages of the “As a user, I want” user story template” Mountain Goat Software (2016, 2004, 2006, 2008)

[2] “Use Case” Wikipedia (2016)

[3] “User Stories” (2016)

[4] Rachel Davies “Agile Coaching” (2015)

[5] “Principles behind the Agile Manifesto” Agile (2010)

[6] “User Story” Wikipedia (2016)

[7] Amir Ghahrai “Acceptance Criteria vs. Acceptance Tests” (2015)