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

Percentiles, Deciles, and Quartiles

Understand the Softmax Function in Minutes