In the traditional software development method, requirements are noted as a handful of documentations, specifications...
In Agile, they are User Story is requirement. User Story is:
- A convenient format for expressing the desired business value
- Crafted in a way that makes them understandable to both business people and technical people
- Used to provide a great placeholder for a conversation
- Written at various levels of granularity and are easy to refine
- Often used with the template:
As a <role>, I want <feature> so that <reason>
Example:
- As a User, I want to login into the system so that I can use other useful features
- As an Admin, I want the system to log the login information so that I can monitor who accesses the system
Epic: A very large user story that will not fit into a single iteration, does not pass the test for inclusion in an iteration, and will need to be subdivided to be considered.
Theme: A collection of features, epics, & stories that describe a broad business purpose.
Sometimes the User Story will also include the design/wireframe for the screen and other extra information and will be logged as an item in the backlog (Like Trello card, Gitlab issue,...)
INVEST is an acronym which encompasses the following concepts which make up a good user story:
- Independent
- Negotiable
- Valuable
- Estimable
- Small (appropriately sized)
- Testable
- User Stories are NOT a final requirement but rather a conversation starter between all roles
- User Stories do not always result in a feature that end-user could use, like Spike User Story
- User Stories are a requirement and also Change Request - because we are living in an Agile world with rapid change, a user story is also a change request, an enhancement, a new feature... and it all should be treated the same and developers should NOT be scared of it