User Story Creation

Learn About User Stories

• What is a User Story?
  • User Stories help translate technical requirements into easy-to-understand ideas
  • Key tool for Salesforce BAs
  • They are a simple descriptions of a feature told from the user’s point of view
  • User stories are used within the Agile methodology
  • They explain the roles of users in a Salesforce system, their desired activities, and what they intend to accomplish
  • User stories don’t outline the entire requirement, but just offer a synopsis of it
  • Benefits of User Stories:
    • Save time whe prioritizing development/implementation of requirements and functionality
    • Focus on how a project can deliver value back to the customer/end-user
    • Focus on customer/end-user success
    • Avoid restrictions that occur when specification details are defined too early
    • Increase collaboration and transparency within the project team
    • Deliver features/products that users actually need
    • Assist in testing solutions
• The Parts
  • Format is intended to be simple and easy to use. Three components:
    • Who: From whose perspective (AKA user persona) within Salesforce will this user story be written?
    • What: What goal will be accomplished/implemented within a Salesforce org as a result of the user story? IE, the user’s goal.
    • Why: Why does the user need the Salesforce functionality or feature outlined in the user story?
  • These parts are arranged into a sentence like this:
    • As a <who>, I want <what> so that <why>.
  • User Story Example: 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.

Construct a User Story

• Assembling the Project Team
  • User-story writing workshops should be held near the start of a project
  • Should include the entire project team: product manager(s), developer(s), admin(s), UX designer(s), users, etc
  • Brainstorm to generate ideas and user stories
  • User stories encourage iterative development and can be refined as needed
  • During this workshop do not focus on implementation or which components will be affected, leave these decisions to the development/implementation team during their planning meetings
• Accept the Need for Criteria
  • Each User Story should have at least one Acceptance Criteria
  • Acceptance Criteria are a set of statements, each with a clear pass/fail result, added to a user story. They specify conditions under which a user story is fulfilled.
  • Should be simple and clear, without any ambiguity about expected outcomes
  • Benefits of Acceptance Criteria:
    • Clarify scope for the project team
    • Assist development/implementation team
    • Ensure testers know what needs to be tested
  • Acceptance criteria should state intent but not a solution - IE, the “what” not the “how”
    • Bad example that focuses too much on solution: A district manager can click Approve/Disapprove button to approve a discounted price.
    • Good example of acceptance criteria that focuses on intent: A district manager can approve or disapprove a discounted price.
  • Consider this 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. Example acceptance criteria:
    • Take ownership of cases from the queue
    • Email customers from the case page
    • Update case details: status, subject, description
  • Acceptance criteria can also be formatted as if/then statements
    • IE: “Email customers from the case page” -> “If on the case page, then the email customer feature is accessible”
  • Example User Story: “As a sales rep, I need the ability to take ownership of a new lead and document the progress so that I can provide consistent insight to my pipeline.”
    • Appropriate acceptance criteria:
      • Able to update lead status with New, Prospecting, Dead or Closed
      • Assign ownership to yourself from the lead queue
      • Access to lead object
• Invest in the User Story
  • Use the INVEST checklist to assess quality of a user story:
    • Independent: not overlapping in concept with another user story
    • Negotiable: not a contract, instead an invitation to a conversation. Captures essence, not details.
    • Valuable: useful to the end user. If no value, then it should not be created.
    • Estimable: timeline can be estimated. Exact timeline is not required, but just enough to help prioritize/schedule story’s development/implementation
    • Small: smaller user stories get more accurate timeline estimates. Details can always be elaborated through conversations
    • Testable: should be able to draft a set of acceptance criteria with the info in the user story
• Mistakes to Avoid
  • Project team didn’t engage in story writing
    • User story will not represent multiple perspectives of the team, so rewrites are likely
    • To avoid: Continuously review and discuss user story with project team, and schedule a story-writing session
  • “Who” of user story is an undefined user
    • Development team will not immediately understand role of the user’s motivations and needs
    • To avoid: Create a list of personas before creating a user story
  • “Why” in the user story is feature specific
    • Story is overly technical and focused on specifics, more like a tool description. User needs are not addressed.
    • To avoid: Keep user’s needs priority number one
  • Acceptance criteria too vague
    • No reliable way to measure when the user story is successfully completed
    • To avoid: ensure all acceptance criteria are independent and can be answered with true or false
  • User story was assigned to implementation team without a team discussion
    • Likelihood of user stories being misinterpreted during development greatly increased, so end product may be much different than original intention
    • To avoid: review stories with your team when assigning them to ensure the team is on the same page
      
      
• These mistakes and other can be avoided when the user story process is properly followed - shortcuts should not be taken
  • Trust the process and end result will be a solution focused on customer/end-user success
    
    
• Acceptance criteria are answered with only a true or false
• Using an undefined user in a user story is detrimental because the intention of the user can’t be clearly defined