How to write a good User Story

User stories are the most popular technique in Agile to capture requirements.

While writing user stories is easy, ensuring that they are effective and to the point requires diligent effort.

What is a user story

A user story describes how a user is going to use the system. It capture's user prospective.

The format of a typical user story is 

As <persona> ,

I want <what?>

so that <why?>

Example : As a student, I want to purchase parking pass, so that I can drive to school

Epic

Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore they need to be dis aggregated into smaller user stories at some point

Theme

A theme is a collection of related user stories. For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing.

Themes are often used to organize stories into releases or to organize them so that various sub teams can work on them.

Elements of a user story

A user story should at minimum have a title. Other good to have elements can be

Description: More detailed description

Acceptance criteria/ Steps to validate   : To ensure the working software meets the requirements of the story
Integration : If the story is about integration with some outside entity
Assumptions : If there were any assumptions made for development of this story
Risks : Are there any risks associated with this story
Design Considerations : What are the design elements to take care of

How to Write It

Step 1 : Identify User Types

A user story describes how a user is going to use the product. So the first step is identify different types of user.

For example an online ticket booking site can have following types of user:

1 An administrator to manage users

2 An administrator to upload to data against which booking can be made

3 A customer of site who would like to book the ticket

4 An sales executing who would like to see reports as to how customers are using the site and what the revenue areas are

5 A Customer care executive to track that customers using the system are not facing any problems.

Step 2: Define Personas

Based on user types identified in step 1 , user personas should be defined. These are distinct roles for which product would be build. All the user stories would cater to requirements of at least one of these personas.

Step 3: Write one liner titles for all use cases you could come up with

Step 4 : Write additional information about user stories like description, validation steps etc.

Step 5 : Repeat the process to identify any missing stories.

How to make sure that it’s effective

Implement INVEST to write good user stories.  INVEST is an acronym which encompasses the following concepts which make up a good user story:

· Independent

· Negotiable

· Valuable

· Estimable

· Small

· Testable

Let’s look at details of each of these items: 

Independent:  Stories should be as independent as possible.   In other words, stories can be worked on in any order.  

Why is this important?  It allows for true prioritization of each and every story.  When dependencies come into play it may not be possible to implement a valuable story without implementing other much less valuable stories.

Negotiable:  A story is not a contract.  A story IS an invitation to a conversation.  The story captures the essence of what is desired.  The actual result needs to be the result of collaborative negotiation between the customer, developer and tester (at a minimum).  The goal is to meet customer needs.

Valuable:  If a story does not add any value to the system, it should not be done. User stories are prioritized in the backlog according to business value. Business value encompasses more than just customer or user facing value.  It includes internal value which is useful for things which are normally called “non-functional requirements” or something similar.  

Estimable:  A story has to be able to be estimated or sized so it can be properly prioritized.  A value with high value but extremely lengthy development time may not be the highest priority item because of the length of time to develop it.  What happens if a story can’t be estimated?  If that is the case we should consider splitting the story to gain more clarity. Sometimes even splitting a story doesn’t help. If this situation occurs it may be necessary to do some research about the story first.  

Small:  Stories are small chunks of work, but how small should they be?  The answer depends on the team and the methodology being used. Ideally a user stories should not be on average more than 3-4 days of work – TOTAL!  This includes all work to get the story to a “done” state.  

Testable:  Every story needs to be testable in order to be “done”.  Acceptance criteria should be written with user stories in order to define done state.