Write user stories

Jul 1, 2013 · 2 minute read · Comments
bdd

Story always involve a User/Customer

A story is associated to a clearly defined user/customer. If not, maybe this feature will benefit nobody and should not be implemented

Before writing stories, we can define personas. that will represent our customers. Then we connect each story to the right persona.

Level of details

It’s hard to get stories’s details correcly. A story should not be too vague and shoud not prescribe the solution because of too much details (should answer what and not how).

Steps to define details:

• Start new features with epics: coarse-grained stories. Epics capture an idea.
• Split epic into more detailed user stories.
• When picking stories for a sprint, these stories should be ready stories that are clear, feasible and testable.

Iteratively refining stories keeps your backlog concise which will help you add new insights.

Involve the team

The team should be involved in writing story details in order to get them ready for the next sprint.

Acceptance and testing

Every story should contain acceptance criteria that will describe the conditions needed to validate a story. The criteria make it more precise and testable.

Example:

As a conference attendee
I want to be able to register online
In order to register quickly
And cut down on paperwork

For the above example, the acceptance criteria could include:

• A user cannot submit a form without completing all the mandatory fields
• Information from the form is stored in the registrations database
• Protection against spam is working
• Payment can be made via credit card
• An acknowledgment email is sent to the user after submitting the form.

Epics do not need acceptance criteria but ready stories should. Defining acceptance criteria with the team during scrums will help them understand the feature from the user’s point of view/perspective.

Note

I write this post after reading this article from Roman Pichler.