Contents 1 Introduction 2 Card Conversation, Confirmation 2.1 Physical v Electronic 2.2 As a product owner I want a template so that it's easy 2.2.1 As a 2.2.2 I want 2.2.3 So that 2.2.4 But the template has it's detractors. 2.3 Start with the end in mind 3 Further reading 4 Related topics

IntroductionEdit

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

User Stories are often conflated with software or business requirements becasue on first impressions they look like requirements. They are actually independent things.

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 daes 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 people's knowledge on the topics area 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 osmotic communication .

Card Conversation, ConfirmationEdit

The three essential elements of a User Story are the card, conversation and confirmation. The se 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 ElectronicEdit

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

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

As a product owner I want a template so that it's easyEdit

Since the mid 2000's a 'common form' of User Story has become dominant. It is presented in the following form;

• As a [user type]
• I want [an interaction+outcome]
• So that [I get some form of value]

The benefits of this templated form are real and tangible.

As aEdit

An important part of both requirements management and workflow management is effective partitioning or dividing of the model elements into smaller parts. Diving the stories by the 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 wantEdit

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 thing. Again partitioning is relevant and important here. But the main driver in this space is to partition the work into a small, independent pieces of work. (See the INVEST mnemonic.)

So thatEdit

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 of the motivation for the requirement. It's also a common client failing to jump to solutions to early. 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.Edit

By proving a tamplate 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 mindEdit

A clear definition of done is important for User Stories as they re 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 advoctes 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 teh 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.

Further readingEdit

• Mike Cohn's User Stories Explained
• Wikipedia on User Stories
• c2.com on User Stories
• ExtremeProgramming.com on User Stories
• Scott Ambler on User Stories
• User Story Template

Related topicsEdit

• INVEST - A quality checklist for User Stories
• Kanban - another concept for work tokens
• Story Maps - a way of managing large numbers of stories
• Behaviour Driven Development
• Requirements as Inventory