User Stories

by Joe Friedman on April 06, 2009

Why we use them, and a few tips on writing superb stories of your own

User stories are the essential element of our development process. They provide a concise way of communicating the requirements, features, and user experience of an application. Once our clients learn to communicate requirements in user stories, they become active participants in the development of their project.

What is a User Story

A User Story describes functionality that is of value to the product owner or user of an application. There are three crucial elements within every User Story:

• a concise, written description of the functionality
• a short conversation that helps flesh out more details of the story
• a test for the story to determine its completeness

Why a User Story?

User Stories emphasize verbal communication among the development team and the product owner. As a result, the client remains an active participant throughout the development process, fully integrated into the creation of the application. Since such strong emphasis is placed on communication by way of User Stories, the product owner is able to add or change features of the project on the fly. We often find that when our clients really take hold communicating requirements in user stories, they realize the full potential of their project and feel they are truly directing the development process.

There are two main reasons why it is imperative that our clients write their own User Stories

1. Since the client will be the party responsible for prioritizing the stories in upcoming iterations, each story must be written in terms of business-value to the client, and not in technical jargon.
2. Clients are the primary visionaries for their product. In this respect, they are the best in describing the behaviors of the application.

Estimating User Stories

User Stories cannot be placed in any order before considering their cost. We estimate our stories based in Story Points. Story Points are a way of assigning a value to the story based on the story’s complexity. For instance, a story estimated at 6 story points will take twice as long as a story estimated at 3 story points. Story Points allow us to easily create and estimate a release plan. By working by Story Points, we can easily track our teams velocity, the rate at which we complete story points. Knowing our velocity enables us to provide our clients with a more accurate time table of their project’s completion.

Effective Story Writing

One of the best ways in which to write a User Story is to use User Role Modeling. User Role Modeling is the practice of creating fictional characters who will be using the application. It is important that these characters, or User Roles, as we refer to them, all have distinct purposes for using the application. In this respect, we are able to put ourselves in the shoes of the end-user of the application to gain new insights into how the system should operate.

Take for instance a job-search system such as Monster. From a development perspective, it is important to understand the different parties who would use such a site. User Roles should be defined for job-seekers, employers, recruiters, and so on. For each role, we like to assign names and create a fictional set of circumstances for each. To use the job-site example, we could create the role of “John”. John is 27, has recently lost his job, and is now looking for a new career. We ask ourselves, how would “John” use this site? What would be important to him? What exactly would he be looking for? In asking ourselves these questions as they pertain to a distinct User Role, we can create effective User Stories that will address the real needs of end-users of the application.

While writing User Stories, we consider as many roles as possible and identify the goals that each user has for interacting with a system.

A few more tips

Stories should be goal-oriented

Every story should end with the user feeling as if they have accomplished something. We refer to this as writing a “closed” story.

Write the stories in an Active Voice

This makes User Stories much easier to read and understand. For example, instead of writing “A resume can be posted by a job-seeker” write “A job-seeker can post a resume”. In this respect, you are viewing the system from the viewer’s perspective.

Have your customers write the stories

It is important to empower your clients with the ability to write their own stories. The development team should always help out, but the product owner is always best positioned to describe the behaviors of the system.

Keep them short

Remember to keep the stories as concise as possible. Ask yourself, what is the sole purpose of this story? A story should effectively communicate one feature of the system only.

Back to top

Home › SI Blogs › Joe's Blog › User Stories