Dear Product Managers,
Give me 2 minutes and I will teach you how to write good User Stories so you can stop confusing your developers!
A short thread 👇
Give me 2 minutes and I will teach you how to write good User Stories so you can stop confusing your developers!
A short thread 👇
Stories are how we understand the world around us.
User stories are how developers understand the needs of the customer.
Learn to write effective user stories.
User stories are how developers understand the needs of the customer.
Learn to write effective user stories.
What is a User Story?
A user story is the description of a feature written from the perspective of the end-user.
NOT from the perspective of the Compliance team & what they think the company policy is!
NOT from the perspective of what the Engineering Manager think is feasible
A user story is the description of a feature written from the perspective of the end-user.
NOT from the perspective of the Compliance team & what they think the company policy is!
NOT from the perspective of what the Engineering Manager think is feasible
Format of User Stories
"As a ____(type of user)____, I want to ____(action/need)____ so I that____(reward/goal)_____"
E.g. "As a user of XZY app, I want to enter my email address and password so I can log in to my action"
"As a ____(type of user)____, I want to ____(action/need)____ so I that____(reward/goal)_____"
E.g. "As a user of XZY app, I want to enter my email address and password so I can log in to my action"
The beauty of the format is that it forces the writer to be concise enough while still communicating clearly; much like the character limit on Twitter
Parts of a User Story:
1. Description
2. Acceptance Criteria
3. Business Rule
Let's take a quick look at each of them...
1. Description
2. Acceptance Criteria
3. Business Rule
Let's take a quick look at each of them...
1. Description.
This is where you describe the feature from the perspective of the end-user...
This is where you write in the format we discussed earlier.
Clear and concise!
This is where you describe the feature from the perspective of the end-user...
This is where you write in the format we discussed earlier.
Clear and concise!
2. Acceptance Criteria
This is a condition or set of conditions that must be met before a feature/functionality could be considered done
This is the definition of done for a feature/functionality
Acceptance criteria are how you tell that the user's requirements have been met
This is a condition or set of conditions that must be met before a feature/functionality could be considered done
This is the definition of done for a feature/functionality
Acceptance criteria are how you tell that the user's requirements have been met
Examples of Acceptance Criteria using the XYZ login story:
* The email field must be clearly marked
* The password conditions must be clearly displayed
* Password is case sensitive
* Email field is NOT case sensitive
* Password must be a minimum of 8 characters & alphanumeric
* The email field must be clearly marked
* The password conditions must be clearly displayed
* Password is case sensitive
* Email field is NOT case sensitive
* Password must be a minimum of 8 characters & alphanumeric
From these acceptance criteria, you can easily tell if a developer has done a good job or not.
Acceptance Criteria helps:
a. Developer- know what needs to be done
b. QA- establish basic testing conditions
c. PM- easily & quickly establish that the user's needs have been met.
a. Developer- know what needs to be done
b. QA- establish basic testing conditions
c. PM- easily & quickly establish that the user's needs have been met.
3. Business Rule
This is a set of policies or regulations, typically, imposed by the company or regulators as a means to shape behaviors on a broader level
Note that Business Rule does not apply to every user story.
This is a set of policies or regulations, typically, imposed by the company or regulators as a means to shape behaviors on a broader level
Note that Business Rule does not apply to every user story.
A good example of a business rule would be placing age restrictions on betting websites to prevent underage gambling.
Now let's give an example of a user story that covers the different parts of a good user story.
"As a user, I should be able to enter my name and age so I can sign up on ABC Sports Betting platform"
Let's break this down!
"As a user, I should be able to enter my name and age so I can sign up on ABC Sports Betting platform"
Let's break this down!
Description- this story is written from the perspective of the user who wants to sign up on the platform of ABC sports betting.
It clearly shows what the user needs to enter to sign up.
It clearly shows what the user needs to enter to sign up.
Acceptance Criteria:
* Users must enter their first & last name
*Users must enter their date of birth in the format DD/MM/YYYY
* Users must enter their first & last name
*Users must enter their date of birth in the format DD/MM/YYYY
Business Rule:
* Only users who are 18 years & above should be allowed to sign up
* Users who are below the age of 18 should be shown the following message:
"Sorry, you are not eligible to sign up until you are 18 years of age or older"
* Only users who are 18 years & above should be allowed to sign up
* Users who are below the age of 18 should be shown the following message:
"Sorry, you are not eligible to sign up until you are 18 years of age or older"
Finally, the "INVEST" acronym is also very helpful when writing user stories.
A good user story must be:
I (independent)- should be complete in itself
N (Negotiable)- should be negotiable as you learn more about the user. It is not cast in stone!
A good user story must be:
I (independent)- should be complete in itself
N (Negotiable)- should be negotiable as you learn more about the user. It is not cast in stone!
V (Valuable)- must provide value to the user
E (Estimable)- easily quantifiable in terms of time or effort required
S (Size appropriate)- must not be too big to estimate or too small that it's insignificant
T (Testable)- must be testable
E (Estimable)- easily quantifiable in terms of time or effort required
S (Size appropriate)- must not be too big to estimate or too small that it's insignificant
T (Testable)- must be testable
INVEST acronym for writing great user stories
I- Independent
N- Negotiable
V- Valuable
E- Estimable
S- Size appropriate
T- Testable
I- Independent
N- Negotiable
V- Valuable
E- Estimable
S- Size appropriate
T- Testable
Don't forget to follow me (@SimplyAzodo )
I tweet about Product Management, Tech, and Productivity.
I tweet about Product Management, Tech, and Productivity.
* "As a ____(type of user)____, I want to ____(action/need)____ so I can____(reward/goal)_____"
Loading suggestions...