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>
- 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:
- Small (appropriately sized)
- 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
1. Start with personas
This is easily the most important step. Make sure to have a solid understanding of user personas in order to craft meaningful stories that actually speak to their needs, goals and frustrations. The personas is the foundation for the rest of the steps in this process, so make sure its compelling and accurate.
2. Take the personas goals and convert them into epics
What goals does the user want to accomplish? Assess these goals and convert them into broad epics. Epics are broad, and define context. The goals of the persona will help determine what functionality our product should include, and epics will give us a big picture idea of what features will look like.
3. Distill persona into roles & epics into stories
Based on who the user is and what’s they’re trying to accomplish, what different roles do they assume?
Then, select an epic and break it down into a more granular form.
The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.