User Stories

Section 0: Module Objectives or Competencies

Section 1: Overview

Requirements determination was discussed in detail early on (link).

• All of the approaches that we discussed are valid with object-oriented analysis and design as well, but we'll add one more approach that has not yet been discussed.
• User stories can be used to capture user requirements and to manage the delivery of user functionality.
• User stories are about all of those in roles requiring interaction with the system or those who realize some value or benefit from the system.

User Stories

Here is a video overview of user stories and story cards:

Section 2: Story Card Details

User stories, along with their associated story cards and task lists, are associated with the agile development approaches.

They are typically captured using story cards (index cards) and are recorded on a task list.

A story card allows you to record a compelling story that tells you what the user wants and why.

• They generally follow the format As a ______ I need ______ so that ______.

• "As a" refers back to the user who wants this piece of functionality.
• "I need" tells us what the user wants.
• "So that" describes why the user wants it, that is, what benefit or value he or she expects to get out of it. Expressing the benefit is important in agile since we want to deliver value to our customers fast with less risk.

Acceptance criteria let the team know when the story is done and are captured in the key statement on the back of the story card.

A story card is only large enough to identify individual requirements.

Stories capture both functional and nonfunctional requirements.

• For example, with regard to the doctor’s office appointment example, a functional requirement-based story could be:
  • As a secretary, I want to be able to schedule appointments for our patients so that we can meet our patients’ needs.
• While an operational nonfunctional requirement-based story could be:
  • As a secretary, I want to be able to print the daily schedule using wireless technology so that all printing can be performed using a shared printer without having to deal with printer cables connecting all of the computers to the printer.

Once the story is written down, it is discussed to determine the amount of effort it will take to implement it.

• During the discussion, a task list is created for the story.
• If the story is deemed to be too large—e.g., there are too many tasks on the task list — the story is split up into multiple stories each being recorded on its own story card and the tasks are allocated across the new stories.
• In many shops, once a set of tasks has been identified with a story, the story and its tasks are taped on a wall together so that all members of the development team can see the requirements.
• The story can be prioritized by importance by placing a rating on the card.
• The story can also be evaluated for the level of risk associated with it.
• The importance level and amount of risk associated with the story can be used to help choose which requirements to implement first.

Section 3: Advantages

The advantage of using story cards and task lists to document requirements is that they are very low tech, high touch, easily updatable, and very portable.

• Both story cards and task lists are considered to be lightweight approaches to documenting and gathering requirements.
• User stories have been shown to be very useful in gathering requirements in a nonthreatening manner that respects the user’s point of view.

Section 4: Resources

10 Tips for Writing Good User Stories

Here is a video overview of user stories:

Finally, here is a LONG video lecture about user stories: