Describing Product Backlog items with User Stories

A user story should be written as a one-liner using the classic template recommended by Mike Cohn:

As a <role>, I want <desire> so that <benefit>.

The core of the story is the “I want <desire>” section. The desire describes an activity done by a stakeholder. A stakeholder is a person who performs a role to satisfy his desire and obtain benefits. When describing a desire, it helps to indicate how it will be used rather than how it might look or how it might be implemented. Look for desires that start with or include an action verb. Here are examples of user stories for the “MTA Self-Serve Smartcard Ticketing Kiosk” software:

As a <student>, I want <to buy a pass valid only on school days> so that I can <go to school>.

The template for user stories helps to answer the classic “Who,” “What,” “Why” questions:

Who = role

What = desire

Why = benefit

User stories are a quick way of documenting a stakeholder’s desirable outcome without being bogged down by the writing of detailed requirements specification. They encourage the team to defer collecting details. An initial high-level story can be written as a first draft and then split into more stories when the team refines the software. Although user stories are not formally recognized as a Scrum practice, more and more teams are adopting this technique for expressing desirements.

A well-written user story follows the INVEST mnemonic developed by Bill Wake [2]. It fulfills the criteria of Independent, Negotiable, Valuable, Estimable, Small, and Testable. Here’s what each criterion means:

• Independent: A story should stand alone and be self-contained without depending on other stories.
• Negotiable: A story is a placeholder that facilitates conversation and negotiation between the team and stakeholders. At any time, the story can be rewritten or even discarded. A story is not fixed and set in stone, up until it is part of the upcoming sprint.
• Valuable: A story needs to deliver value to the stakeholders (either the end user or the purchaser).
• Estimable: The team needs to be able to roughly estimate the size of the effort to complete the story.
• Small: A story can start its life as a big placeholder. As time goes by and you better understand the intricacies of the desires, the placeholder will be split into smaller stories. When the most important ones are close to being delivered, they need to be small enough so that they can be completed in a single sprint.
• Testable: A story must provide the necessary information to clearly define the acceptance criteria that confirm the story is completed.

Specifying the requirements from a single perspective does not reflect the experiences, backgrounds, and desirements of every stakeholder. While writing stories, it is important to identify all the stakeholder roles that the software must absolutely and positively satisfy. It is unusual that stakeholders come down to a single role. This is why the template for user stories begins with the section “As a <role>, I want ....” It reminds us that there are several types of stakeholders.

A role is a collection of stakeholders pursuing the same desires while interacting with the software. A single stakeholder can fulfill more than one role. Whenever possible, stick with roles that define people as opposed to systems. However, consider a nonhuman role if you think that it may make or break the success of the software.

A role must have a unique name that differentiates it and sets it apart from others, especially when it is read in user stories. For example, student, tourist, and worker are all good candidate stakeholder roles for “MTA Self-Serve Smartcard Ticketing Kiosk” software:

As a <student>, I want ...

As a <tourist>, I want ...

As a <worker>, I want ...

In addition to retrieving the names of roles in the stories, some teams may feel the need to specifically record stakeholder roles with a short description. Any useful information that helps distinguish one role from another can be part of the written description. However, the aim of role modeling is not so much to create personas but to discover missing stories. By sorting stories by role, the missing desires for each stakeholder are highlighted.

As a <student>, I want <to buy a pass valid only on school days> so that I can <go to school>.

As a <student>, I want <to buy a monthly pass> so that I can <go to school and get around>.

As a <tourist>, I want <to buy a daily pass> so that I can <visit the city for one day>.

As a <tourist>, I want <to buy a multiple day pass> so that I can <visit the city for more than one day>.

As a <worker>, I want <to buy a monthly pass> so that I can <go to work>.

It should be noted that even if the desire <to buy a monthly pass> is the same for the worker and the student, it is important not to consolidate the story into one. The benefit sought is probably not the same because the role is not equivalent. Usually, each role expects a specific behavior and requires a different experience.

Similarly, another technique for discovering missing stories is to focus on the expected benefits. Rather than promoting the roles, use a different template for writing a user story, moving <benefit> forward in the phrase to emphasize it:

In order to <benefit>, as a <role> I want <desire>.

Sorting user stories by benefit can help you easily discover if there are missing desires:

In order to <go to school>, as a <student> I want <to buy a pass valid only on school days>.

In order to <go to school and get around> as a <student>, I want <to buy a monthly pass>.

In order to <visit the city for one day> as a <tourist>, I want <to buy a daily pass>.

In order to <visit the city for more than one day>, as a <tourist> I want <to buy a multiple day pass>.

Storyboarding is a great way to communicate design ideas to teams, stakeholders and end users visually. As with high-fidelity prototypes, visualizing a design idea with an interactive storyboard will help the audience remember as well as empathize and engage with it.