IT:AD:User Story

Summary

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.


Resources