IT:AD:User Story

Notes

A User Story is the IT:AD:Agile equivalent to a User Requirement (see IT:AD:Requirements).
It is written in the language of the System/End Users (whether they be Business Users or Business Customer Users).
It does not contain the design detail one would expect to find in a System Design Requirement.
The most common syntax used is “As a <role>, I want <goal/desire> so that <benefit>“
- A suggested alternate is to “hunt the value”: “In order to <receive benefit> as a <role>, I want <goal/desire>“
Advantages:
- Written in the language of business users, therefore good conversation starters.
- The Agile process requires constant business engagement.
Considerations:
- A user story is an informal statement of a requirement.
  - The User Story's corresponding Acceptance Tests are required.
Disadvantages:
- Incomplete specifications that on their own are considered weak and open to interpretation.
  - This leads to several risks:
    - the Developers must remember to refer separate NFR documentation at all times.
    - Acceptance tests have to refer to separate Supplemental/NFR documentation.
    - Differences interpretations will occur.