User stories are a simple, concise method for defining pieces of functionality from the user's perspective. A user story is often expressed in a simple template:
As a [type of user], I want [some goal] so that [some reason].
This format helps keep the focus on the user’s needs rather than the technical details of how the feature will be implemented.
Beyond the basic structure, user stories may also include:
- Acceptance Criteria: Specific, agreed-upon conditions under which a user story is considered complete and functions as intended. This is crucial for testing and validation.
- Attachments: Diagrams, mockups, or other visuals to clarify the requirements or expected outcomes.
- Comments/Notes: Any additional information that can help the development team understand the context or details of the user story.
Flow of a User Story:
US: Basic SAFe team workflow_general
US: Basic SAFe team workflow_Salesforce
THIS IS A DRAFT
In Refinement - Functional and technical analyses should be done during this stage in order to prepare to the next step
Ready for Sprint - All requirements are clear and user story is ready to planning. The definition of ready needs to be met on this stage.
In Development - User story was planned and is in process of development by team
In Testing - User story in process of testing by team
*Ready for INT - User story is ready for testing in INT sandbox
*Int testing - User story is in testing in INT sandbox during the release cycle
Ready for UAT - User story is in testing by PO to validate it readiness to UAT
In UAT - User story is in testing by business/users
Ready for release - User story passed UAT and ready to be released. The definition of Done needs to be met.
Released - User story was released to Production
Closed - Final validation of delivered user story by PO
Blocked - User story can be blocked during all stages of this workflow
Rejected - If user story in not relevant anymore it should be Rejected
*Salesforce projects only
For the User Story to be " add state here link" The definition of ready needs to be met,
For the User Story to be " add state here link" the definition of Done needs to be met
Definition of Ready ensures that a user story is fully prepared for development, minimizing the risk of rework or delays. A user story is considered "ready §§" when it meets the following criteria:
- Clear and Concise: The user story is well-written, with a clear description of what needs to be done, including the desired outcome.
- Acceptance Criteria Defined: Acceptance criteria are specific, measurable, and testable conditions that must be met:
- Prioritized: The story is prioritized in the backlog, and its priority is understood by the team.
- Dependencies Identified: All external dependencies (on other teams, systems, or stories) are identified:
- Sufficiently Sized: The story is small enough to be completed within a single sprint and is estimated by the team. If it is too large, it should be split into smaller, more manageable stories.
- Team Understanding: The development team fully understands the story and what is required to complete it. Any questions or ambiguities have been addressed:
- Technical Aspects Considered: Any technical requirements, architectural considerations, or constraints have been identified and discussed.
- Ready for Testing: The story includes all necessary test cases, and the testing strategy is clear.
Definition of Done is a shared understanding within the team of what it means for a user story or task to be complete. A user story is considered "done" when it meets the following criteria:
- All Acceptance Criteria Met: The user story fulfills all the acceptance criteria outlined in the Definition of Ready.
- Code Complete: The code has been written, reviewed, and meets the team's coding standards.
- Code Reviewed: The code has been peer-reviewed, and all identified issues have been resolved.
- Tested All unit tests, integration tests, and any other relevant tests have been written, executed, and passed. The code should be free of critical bugs.
- Deployed to ???? : The story has been deployed to a staging environment and verified as functioning as expected
- Documentation Updated: Any necessary documentation, including user documentation, technical documentation, or inline code comments, has been updated.
- User Acceptance: If applicable, the feature has been demonstrated to stakeholders, and feedback has been incorporated.
- No Open Defects: There are no open defects or bugs related to the user story. Any minor issues are documented and agreed upon to be handled separately.