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 . It fulfills the criteria of Independent, Negotiable, Valuable, Estimable, Small, and Testable. Here’s what each criterion means:
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 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>.
Each user story should be enhanced with a storyboard.
Explaining requirements from the perspective of the user interface helps to turn unspoken assumptions into explicit information. In addition, explicit information helps stakeholders think and communicate effectively. To keep up a healthy conversation between stakeholders, the product owner, and the developmentteam, each user story should be enhanced with a storyboard. During specifications, the screens required to illustrate the user story are roughly sketched, either on paper or through the use of computer-based software.
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.
© 2020 Digcode.com. All rights reserved.