User Stories

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)

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].”

User Story Version Control Repository to Manage Scope (86)

User Story Practice Questions on Trailhead (87)