Best Practices To Write User Stories
The following workflow helps user to develop best stories:
- What and for whom are you trying to provide a solution?
- How do you want to solve this problem?
- What value can you bring out of the story?
- Acceptance criteria
Provide a Solution – ‘What’ and ‘Who’
This initial step in the user story writing process is the first one to focus upon. What are we writing? And whom are we writing the user story for?
Who are the Users?
A user need not be specifically the end user who uses the product. Users can also be members of the Product management team. Anyone who is in the capacity to add a feature can also write a user story.
What to write?
A general template, as mentioned above can be used to describe the intention of the user. Few examples can be, “I want to add a new feature”, “I want to upload a document”, ” I want to add a product to the wish list”.
Few points to keep in mind while describing the story are to keep it short, simple and technical details need not be added.
Solve the “How?”
“Solve by breaking down “. In order to develop the User Stories, the Product Management Team must break down the Features.
After breaking down, if a single fragment provides a deliverable value to the solution then that becomes a User Story.
The below mentioned points will help to resolve how to write the user stories,
- Describe the user stories and define what the user story is about and who is writing it.
- Breakdown the user stories into tasks if necessary and if they are further divisible. This is optional.
For example, the user story described as below
“As a Registered User, I want to protect my login authenticity from any device while I login so that I feel secured”
The above user story can further be divided into tasks such as:
“Pop up message on phone to allow me to login”
- Outline the stories and order them. Outlining the stories will give a broader vision to see if it creates any deliverable value to the user. Ordering the user stories will create a sequential execution.
- All the stories must be completed within a sprint’s time. If a story is taking a week’s time then they must be further divided such that any story will take only a sprint’s time for its execution.
Make User Story Value Driven
User stories are User centric as they are simple descriptions that are written keeping the end user’s perspective in mind.
They are the answers to “Who”, “What”, “Why” vital questions
User Stories are meant to place the User first in the whole Product Development phase. It’s a single idea or a thought or a requirement that provides value to the customer there by adding value to the entire product.
Some points that must be considered to make the story value driven are:
– Any Unnecessary information that do not add information value must be removed
– Using complex and technical words that cannot be understood by the user must be avoided
– The words must be simple, clear and small such that they are user readable
Acceptance Criteria
An acceptance criterion is a set of rules which the user story should meet in order to be accepted by the Product Manager or the user.
This is a part that is staged at the user story completion and at the beginning of testing.
Whilst user story defines the functionality of a feature, Acceptance Criteria defines the “Definition of Done” for the user story.