User Stories
These notes were taken while studying using Mike Wheeler's Salesforce Courses.
User Stories Introduction (76)
- Learning objectives:
- Understand the components of a user story to perform thorough analysis
- Contrast the difference between acceptance criteria vs definition of done
- Document user stories in a version controlled repository to manage scope
Who? What? Why? The components of a User Story to Perform thorough Analysis (77)
- Components of a User story: Who, What, and Why
- Ex: As a customer care representative, I want to take ownership of new cases and communicate with customers so that I can provide high-touch customer experiences.
- When formulating user stories with the project team, don’t make any assumptions about how the user stories will be implemented
What before How (78)
- Implementation (“How”) should follow a clear articulation of what needs to be done (“What”)
Establishing Acceptance Criteria (79)
- Acceptance Criteria are an agreed upon gauge of success - they specify conditions under which a user story is fulfilled
- Specifically, they are a set of statements each with a clear pass/fail result, that are added to user stories
- Bad example: A district manager can click on Approve/Disapprove button to approve a discounted product price. - too specific on implementation
- Good example: A district manager can approve or disapprove a discounted product price.
- For the user story: As a customer care representative, I want to take ownership of new cases and communicate with customers so that I can provide high-touch customer experiences., the following are possible acceptance criteria:
- Take ownership of cases from the queue
- Email customers from the case page
- Update case details: status, subject, description
- Acceptance criteria can be formatted as if/then statements. Ex: If on a case page, then the email customer feature is accessible
- Every user story should have at least one acceptance criteria
- Acceptance criteria should be independently testable and answerable with a true or false
INVEST Checklist (80)
- INVEST checklist is used to assess the quality of a user story. INVEST:
- Independent, Negotiable, Valuable, Estimable, Small, Testable
- Original Article on INVEST Criteria
Definition of Done (DoD) (81)
- Understand Why Salesforce Adopted Agile
- Definition of Done: set of guidelines that dictates everything a team is required to do before they can call the work truly done
- Goal of Definition of Done is to create clarity and alignment around when something is done
Prioritizing User Stories (82)
- User Stories must be completed, or you may not be using agile correctly, and instead exhibit False Agility
Acceptance Criteria vs Definition of Done (DoD) (83)
- Definition of Done is a list of requirements that a user story must adhere to for the team to call it complete. Acceptance Criteria of a User Story consists of a set of Test Scenarios that are to be met to confirm that the software is working as expected.
- Difference: DoD is common for all User Stories whereas Acceptance Criteria is applicable to a specific User Story
- Both DoD and Acceptance Criteria must be met in order to complete the User Story
Setting Up and Viewing Debug Logs (84)
- View Debug Logs
- Access via: Setup > Quick Find > “debug” > Debug Logs
User Story Template (85)
- Atlassian Reference on User stories with examples and a template
- “As a [persona], I [want to], [so that].”