Writing better User Stories

Beginner

difficulty

Stage 2

Agile IQ® Level

Backlog Management

Practices

XP

Framework

Introduction

The User Story format originates from Extreme Progamming (XP). It is just one of many ways to write, define, and communicate Product Backlog items. Learning all of these formats will assist you in communicating:

The needs of users.
The logic of the flow of actions for features.
The constraints of the organisation, including business rules and compliance needs.

Stories in Scrum

Scrum uses the more generic term “Product Backlog item” to describe the items of work in the Product Backlog. Importantly, Scrum is agnostic of the format used to describe those items. Teams are free to use the User Story format, the Three Cs, or even INVEST.

Stories in SAFe®

SAFe® uses Stories to describe the items of work at a team level, Features at an Agile Release Train (program level), and Epics at the portfolio level. Overall, SAFe® has 9 different types of ways to write backlog items in their requirements model depending if they backlog item is defined at the portfolio, Agile Release Train, or team-level.

Purpose

In XP, User Stories serve the same purpose as use cases, but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are typically written by the XP Customer as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.

User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.

Myths

One of the biggest misunderstandings with User Stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the Story, developers will go to the XP Customer and receive a detailed description of the requirements face-to-face.

Another difference between stories and a requirements document is a focus on user’s needs. Avoid details of specific technology, data base layout, and algorithms. Instead, keep stories focused on user needs and benefits as opposed to specifying the technology solution.