How to Write User Stories

How to Write User Stories
By Manoj Gupta

Definition of User Story

“User Story is a description of a requirement and its business benefit, and a set of criteria by which we all agree that it is ‘done’ “

So, User stories are statements to capture the requirements of the product/project as told by end user. The whole project is basically defined as a set of stories. Some time the stories are so big, we need to break them in smaller stories. The big stories which can further be broken are known as “epic”.

Characteristics of User Stories

1. Make them customer-focused: Stories should be user or customer focused, not the developer focused. They should be valuable to user of the solution. Written in user’s language. They should be features not tasks.

2. Make them elevator-friendly: A good story should be something you could explain on an elevator in 30 seconds or so to a team member. Don’t write novel.

3. Make them the right size: Not too big, and not too small!! For me, the right size is usually under 40 ideal hours (1 ideal week) of estimated effort. Club the stories which are under 1 hour in a bigger story.

4. Make them estimatable: They need to provide enough information to estimate, without being too detailed.

5. Make them independent: it’s an important aspiration. User Stories should be as independent as possible.

6. Make them negotiable: User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.

7. Make them testable: Very important!!, the story will not be completed unless it passes acceptance test. So User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

This is just scratching the surface of the topic, but I hope these tips give you a little direction when starting to write stories.

Structure of a User Story

“As a [user role], I want to [feature/goal] so that I can [reason]”

A User Story should focus on the who, what and why of a feature, not how.

For example, on a job site, two high-level User Stories might be:

• As a job seeker, I want to search for a job, so I can advance my career.
• As a recruiter, I want to post a job vacancy, so I can find a new team member.

Pretty easy right? However, in some instances I find that the “so that” suffix reads redundantly so go ahead and have that be optional if you wish.

As an account owner, I can check my balance online.

Feel free to use slight deviations of this template using synonyms:

• As a [role], I want [feature] because [reason]
• As a [role], I can [feature]
• As a [role], I can [feature] so that [reason]

Acceptance Scenarios

This is not, in my opinion, where a store ends. To give some context and specification to the story, We should have defined acceptance criteria to know when the story can be deemed as “done”. The acceptance tests can be written using this template

Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…

For example

Scenario 1: Account balance is negative
Given the account’s balance is below 0
And their is not a scheduled direct deposit that day
When the account owner attempts to withdraw money
Then the bank will deny it
And send the account owner a nasty letter.

So Now….

At the start of a project, capture an initial list of User Stories up-front. Like I have said before, write out all the possible user stories you can currently think of. I guarantee that you will be missing some of the project scope; however with a little luck, you will be able to connect the dots and see the entire project picture.

In Scrum this would be the initial Product Backlog. This feature list is useful for estimating and planning. But defer capturing the details until the story is prioritized and due to be developed in the next Sprint or iteration.

So, together, the “As an user, I want to so I can ” story-definition pattern, a name for the story, and a context specification together create a backlog item that can be scheduled for an iteration.

Manoj Gupta is a dynamic professional with @ 13 Years of Rich Experience In Software/Product Development Life Cycle , Project Management , People Management , Delivery Management, Planning and execution. Manoj’s blog can be found at: http://manojgupta2000.wordpress.com/.