# IT:AD:User Story #


<callout type="Navigation" class="small">

* [[../|(UP)]]
* See also:
  * [[IT/AD/Use Case/]]
  * [[IT/AD/Edge Cases/]]
  * [[IT/AD/Acceptance Test/]]
    * [[IT/AD/Testing/]]


</callout>


<panel title="Summary">



</panel>


## Notes ##

* A *User Story* is the [[IT/AD/Agile/]] equivalent to a [[IT/AD/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 [[IT/AD/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.
        




## Resources ##

* https://en.wikipedia.org/wiki/User_story