What is a User Story?
A user story is an end goal expressed from the end user’s perspective. User stories also encompass the acceptance criteria, the benchmark to determine when story is complete or what can be shown at a demo.
Why create User Stories?
The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer.
Benefits of user stories include:
Avoids introducing too much detail too early that prevents a negotiable design
Divide work into small enough pieces to accomplish iterative development
Leaves technical functions to the tech team
How do I write a User Story?
User Story
As a — this is the WHO. Who are we building this for? Who is the user?
I want — this is the WHAT. What are we building? What is the intention?
so that — this is they WHY. Why are we building it? What is the value for the customer?
Acceptance Criteria
Given — What context needs to be true for end result to occur?
when <user/system action> — What action is carried out?
then — What are the particular set of observable consequences?
Note: Acceptance Criteria can be written in several different ways, but the above suggested format helps Product to better visualize and plan for the user journeys.
What makes a good User Story?
Independent: Stories should be as independent as possible so that stories can be freely re-ordered in the product backlog without dependencies .
Negotiable: Story needs to be written in a way that the team can negotiate a concrete solution to implement.
Valuable: Each story must add something useful to the end user/customer.
Estimable: Must contain enough information to determine rough approximation of effort.
Small: Story must fit in a single sprint based on Definition of Done by each Scrum team
Testable: Story must be written in a way that the QA team can create a test case based on the Acceptance Criteria
micharubin-pdm
commented
1 year ago 
What is a User Story? A user story is an end goal expressed from the end user’s perspective. User stories also encompass the acceptance criteria, the benchmark to determine when story is complete or what can be shown at a demo.
Why create User Stories? The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer.
Benefits of user stories include:
Avoids introducing too much detail too early that prevents a negotiable design
Divide work into small enough pieces to accomplish iterative development
Leaves technical functions to the tech team
How do I write a User Story? User Story As a — this is the WHO. Who are we building this for? Who is the user?
I want — this is the WHAT. What are we building? What is the intention?
so that — this is they WHY. Why are we building it? What is the value for the customer?
Acceptance Criteria Given — What context needs to be true for end result to occur?
when <user/system action> — What action is carried out?
then — What are the particular set of observable consequences?
Note: Acceptance Criteria can be written in several different ways, but the above suggested format helps Product to better visualize and plan for the user journeys.
What makes a good User Story? Independent: Stories should be as independent as possible so that stories can be freely re-ordered in the product backlog without dependencies .
Negotiable: Story needs to be written in a way that the team can negotiate a concrete solution to implement.
Valuable: Each story must add something useful to the end user/customer.
Estimable: Must contain enough information to determine rough approximation of effort.
Small: Story must fit in a single sprint based on Definition of Done by each Scrum team
Testable: Story must be written in a way that the QA team can create a test case based on the Acceptance Criteria