Writing Good User Stories
How to write good user stories
Good user stories are the backbone of a project – ok, that might be dramatic but it is an output that if done badly, can affect a project's timeline and quality. To write good user stories, we need to look at what constitutes a good one!
First things first user stories should be easy to understand. Leave flowery or tech speak at the door please! Focus on real users and real user flows and they are small enough to be independently delivered and tested (and signed off!).
A good user story should follow the INVEST model
1. Independent
2. Negotiable
3. Valuable
4. Estimable
5. Specific
6. Testable
There are three key elements to a user story, the Description, the Assumptions and most importantly, the Acceptance Criteria.
The Description
What
The Description is a short narrative of the feature that can be easily understood by people familiar with the topic.
The who, what and why.
How
Narrative format:
As a [who] I want to [what] so that I can [why]
Think before you write
Did I include the word ‘and’?
If you need to use the word ‘and’, it may not be specific enough and you need to write a new user story!
Assumptions
What
The Assumptions are items that must be in place in order for the user story ‘start’ or ready.
The Definition of Ready
How
The assumptions should be itemized for ease of reading. They might include items like ‘User has relevant permissions’
Think before you write
What do I need in place in order to begin this story?
It might be security permissions or other stories that provide a ‘flow’ to the user. Try linking to other user stories to help give the reader context
Acceptance Criteria
What
The Acceptance Criteria is the success of the user story. It defines what success looks like for the user.
The Definition of Done
How
The acceptance criteria should be itemized for ease of reading. Each line item should reference the user and not the system.
Example:
1. User can view that status has automatically updated to active.
Think before you write
Is there any question unanswered in the user story?
If there is something left unsaid in the user story, it is likely no specific enough. Try asking yourself if the developer has all they need before closing off a user story.
Is the language clear?
Try using language that your stakeholder will find easy to understand, they are your approver, make sure it works for them first! Secondly, ensure the developer and test lead be able to interpret and make their own specific tasks/test cases.
Summary
In summary; a good user story should remove the risk of misinterpretation of requirements by stakeholders, provide detailed user steps for developers, and should reduce challenges in test case creation. If you approach user stories as if you are telling the story of a process, it will flow nicely and will naturally be easier to communicate your requirement.