User Story

Description of a user story in agile

A user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. It is commonly used in Agile-based software development projects to capture requirements.

User story is a format for expressing business value of backlog items, especially features. They are written in a form that is understandable to both business and technical people.

Template for a Good User Story

A good template for a user story is to express it in terms of who, what, and why as shown below:

“As a [persona], I want [functionality], so that [benefit].”

Some example of a good user story:

  • As a user of the PMP exam simulator, I want to be able bookmark exam questions, so that I can review them later.
  • As a moderator of the forum, I want to be able to ban users, so that I can keep the discussions meaningful.
  • As a customer of the ecommerce site, I want to be able to read product reviews, so that I can make an informed purchase decision.

Three C’s of a User Story

The three C’s of a good user story are:

  • Card
  • Conversation
  • Confirmation

Card

Card refers to the description of a user story. A good user story is usually brief such that it can fit on a 3x5 index card. The template and examples provided above illustrate this point.

Conversation

Though a user story itself is brief, the details must emerge through conversation between the business representative (usually the product owner), and the project team members. This also reflects the agile value of “Individuals and Interactions over Processes and Tools”.

Confirmation

Confirmation refers to the acceptance criteria of the user story. The project team members must have a clear understanding of the acceptance criteria before they start working on a user story.

Characteristics of a Good User Story

The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. It stands for:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

For example, a user story that says “the application should be fast” is not considered good because it’s not testable.

Read the article INVEST in Good Stories, and SMART Tasks for a more in-depth understanding.

Notes

  • Acceptance tests are used to confirm individual user stories.
  • Done Criteria are a set of rules that are applicable to all user stories in a given iteration.
Last updated: February 20, 2021