User Story

Introduction[]

A User Story is a marker indicating a request for work to be done.

User-stories-4 — User Stories image cc from http://libwebrarian.wordpress.com/tag/user-stories/

User Stories are often conflated with software or business requirements because at first impression they look like requirements. However, they are different.

User Stories were first introduced to the world by the XP community in the late 1990s, although the concept of stories and narratives being effective tools for communicating requirements dates back at least into the early 1980s.

Important things to consider about User Stories

They are a token for doing a piece of work and are not a software requirement in the traditional sense
They are a 'trigger for a conversation ' and build upon the Agile Manifesto principle that face-to-face conversations are the most effective form of communicating ideas
A User Story is likely to evolve over time as knowledge of the topic matures
Generally, when a software team starts work on a User Story a clear 'definition of done ' should be available
User Stories are ideally written on index cards or similar because of the value of visualizing the workflow, keeping them simple, and the inherent value of osmotic communication .

Card, Conversation, Confirmation[]

The three essential elements of a User Story are the card, the conversation and confirmation. These are described below under the following headings.

Card: Physical v Electronic
Conversation: As a Product Owner I want a template
Confirmation: Start with the end in mind

Physical v Electronic[]

User Stories are typically written on index cards or Post-it notes because of the value of osmotic communication, the lightweight nature of the tool, and because face-to-face communication is optimal for project team communication.

Many teams also capture User Stories in electronic media such as requirements management or test tools. There are many purpose-built product backlog management tools on the market.

As a product owner I want a template so that I can easily communicate requirements[]

Since the mid 2000's a common form for the User Story has become dominant. It is presented as such:

As a [user type], I want to [an interaction+outcome], so that I can [get some form of value]

The benefits of this templated form are real and tangible.

As a [user type][]

An important part of both requirements management and workflow management is effective partitioning or dividing the model elements into smaller parts. Dividing the stories by user type is a useful technique. Occasionally a feature or service will be identical for multiple users but more often than not there are differences, subtle or obvious, that the division helps surface.

I want[]

This generally describes some tangible interaction or feature. Because of this element a User Story is often conflated with a Use Case, a scenario or a feature. And it may well describe any of these or other things. Although partitioning is relevant and important here, the main driver in this space is to partition the work into small, independent pieces of work. (See the INVEST mnemonic.)

So that[]

Software developers usually have a lot to offer in relation to requirements and how they should best be fulfilled. Often they have been constrained by a lack of awareness or motivation for the requirement. Jumping to solutions too early is also a common client "fail". Asking for the motivation in terms of business value helps everyone focus on what's most important in the story.

But the template has it's detractors.[]

By providing a template in the first place, you provide a platform for people to communicate in written form with the idea that the communication is sufficient and complete. Unlike requirements, a User Story is not a complete brief. It is aimed at being a trigger for a conversation and is purposefully incomplete so that the conversations can be had to further elaborate understanding collaboratively.

Start with the end in mind[]

A clear definition of done is important for User Stories as they relate to work requests. By being clear about 'done,' teams are better able to determine when they have not yet met the minimum quality and capability thresholds, and when they have gone too far.

Typically the definition of done is created via a test case or acceptance criteria prior to commencing work on the user story. Early User Story advocates simply used the trigger "This will be done when..." to stimulate the discussion on 'done.' More recently the idea has been elaborated.

From the same vector as the "As a... I want... So that..." template comes Behaviour Driven Development (BDD.)

BDD is more than just a form for acceptance criteria. It is also a framework for managing stories and requirements more broadly. But it has also been adopted as the dominant form for acceptance criteria on User Stories with the template;

Given
When
Then

Where 'given' describes a starting state, 'when' describes a trigger or catalyst and 'then' describes the new state of being. This template form suffers the same strengths and weaknesses as the "As a I want" template.