User Story

User Story basics

A user story is a description of a requirement from a user's point of view. Although not a scrum artifact strictly speaking, in industry each product backlog requirement is usually maintained in the form of a user story.

User stories are usually written on three by five-inch cards. Small enough to carry and pass around the team, but large enough to write a description and acceptance criteria on.


User Stories – The Three Rs

------------------------------------ 
|  As a <role> 
|  I want <requirement> 
|  So that <reason/ROI> 
------------------------------------


------------------------------------ 
|  As an F1 game player                      
|  I want to see a circuit  map      
|  So that I know where I am on the circuit            
------------------------------------

Acceptance Criteria
They should translate into 'acceptance tests’ that a tester (or quality assurance tester) can use to verify the quality of a feature.  A tester should be involved in writing them, but it is a product owner's responsibility to produce them.  Agile business analysts are very helpful in assisting product owners and extracting the right information for user stories.

|  A <role> should <see/be able to do> the following: 
|     - <AC1> 
|     - <AC2> 
|     - <AC...> 

|  Edge Cases:
|    - <EC1> 
|    - <EC2> 
|    - <EC...>
------------------------------------


note:
Also, note that edge cases are separated out.  This is not a necessity, but in my experience, it helps to force thinking of tricky situations that may arise.





Comments

Popular posts from this blog

Maxpooling vs minpooling vs average pooling

Generative AI - Prompting with purpose: The RACE framework for data analysis

Best Practices for Storing and Loading JSON Objects from a Large SQL Server Table Using .NET Core