Menu

User Stories

Short Tip: A reminder of a necessary product requirement.

What is it?

A user story is a technique used to capture a need for the product. Unlike other methods of detailed requirement specification (e.g., use case), a story contains just the necessary information for a conversation between the development team and the Product Owner about the user’s need.

User stories usually follow the 3C’s designed by Ron Jeffries:

  • Card: the stories must be written on cards without enough space for a detailed specification;
  • Conversation: the requirement should be communicated to the team through a conversation, not a formal document;
  • Confirmation: there should be a method to check whether the story was written as discussed – usually through acceptance criteria.

Why use it?

Because it is simple and quick, the user story is adequate to capture a need without wasting time on excessive details. This approach is in line with the “individuals and interactions over processes and tools” principle in the Agile Manifesto.

How to use it?

Although not mandatory, the most common standard for writing a user story is based on the “As/I want/to” template, as shown below.

As ______________________________ (product’s user type)

I want ___________________________  (requirement)

so that _______________________________ (the need to be met)

In order to guide the development team on how a story will be evaluated by the Product Owner, it is common to write the acceptance criteria on the back of the story card. The following template is recommended:

Given ____________________________ (the action’s pre-condition)

When ______________________________ (the action on the product)

Then _______________________________ (the behavior expected from the product)

A good user story must also go through the INVEST test designed by Bill Wake.

  • I (Independent): the story should be as independent as possible from other stories, to the point that its position in the backlog can be changed without further impacts;
  • N (Negotiable): the story shouldn’t be rigid; it should generate an open, flexible discussion;
  • V (Valuable): the release described in the story should generate value for the product’s user;
  • E (Estimable): the Developers should be able to estimate the story;
  • S (Small): the story should be small enough to fit in a Sprint;
  • T (Testable): the Development Team should agree on how the story will be evaluated based on tests. Acceptance criteria are normally used for that purpose.