Writing Salesforce Requirements Dramedy

Intro

• Presenters are from Mavens, a salesforce.com implementation partner focusing on healthcare and life sciences especially pharmaceuticals
• “Dramedy” includes:
  • Hero: Salesforce Admin
  • Sales manager that challenges hero
  • Fairy godmother, enlightening figure who advises Salesforce Admin
• Will also demo a simple requirements management app that can be readily built in Salesforce

• Illustration above demonstrates the real-world challenge that we all face
• Any single project begins with a very simple goal in mind (shown on right side): a very simple rope swing
  • But, without a means of defining requirements, or a proper procedure for going about gathering information and formulating it, it is easy to for different people throughout the process of a project to have a different understanding or different interpretation of the requirement and ultimate goal

Act 1, Scene 1 - Enter Sales Manager, Exit Rationality

• Requirements from Sales Manager:
  1. Manage Renewals - turn that on…
     • Had it at a previous company
  2. Start selling our own support in Salesforce in 2 months
     
     
• This might feel familiar to admins/consultants
• “Big shots” can be familiar with Salesforce but may think of Salesforce as something where we just toggle things on and off, not realizing that the platform by design is endlessly customizable
• They often know enough to be excited about Salesforce, but not enough

Act 1, Scene 2 - Epiphany, Admin Hero receives enlightenment

• Admins are in a good position to help their stakeholders, but first you need good information
• First, draft up some requirements to demonstrate your business acumen and get a running start
• Focus on “Who, What, Why” - Who needs to do What and Why (for what business reason)
• Prioritize your workload - just make sure you have a plan in place to go about refining your understanding ahead of the deadline

Example App for Managing Requirements and Requests

• Use the power of the platform to track requirements - for example use an app developed by the Maven team that leverages the console UI:
  • Highlight panel at the top includes the User Story, which encompasses the Who/What/Why

• List views are available on the left (Icebox, Backlog, In Progress, Done) with the various statuses
  • Icebox contains the unrefined requirements that aren’t well understood by the data team yet
  • Backlog contains refined requirements that have been distilled into user stories, and which the admins have committed to delivering
    • Items in the Backlog cannot be changed
    • Nobody moves anything into the backlog without admin’s agreement
  • In Process contains requirements that in process of being built out
  • Done can mean different things to different companies. Examples:
    • Tested, deployed to production, ready for use by users
    • Completed in a Dev org, pending testing and/or deployment to production

• Chatter is used in the middle to track progress working through certain requirements using a feed-based layout
• Quick Actions are available to update the Status field, and the feed-based layout timestamps these changes
• Acceptance Criteria is a separate object that looks up to requirements and is contained in a related list
  • User Stories captures the “top-level” detail that summarizes the requirement
  • Acceptance Criteria are the specific actions users need to be able to perform in order to successfully meet the overall requirement. Answerable with a Yes/No.
    • Ex: When a new business Opp is Closed Won, a Contract is created related to the Opp.
    • If you can answer Yes to all Acceptance Criteria, you consider the overall requirement satisfied
    • Used in testing/training and to ensure that business stakeholders have a clear, concise, shared, common understanding between Salesforce admins and business stakeholders
• Access to these objects/records can be shared with Salesforce users/business stakeholders so they have clarity

Act 2, Scene 1 - The Reckoning, Sales manager gets Admin Hero Treatment

• After reflecting on the original request, revise the requirements to include user stories and business logic, then present back to the business stakeholder for their review/confirmation

Further Learning Points

• Gather quick, first-pass requirements up front, then “refine your understanding of their needs” and present them back to the stakeholder to make sure they’re still aligned
• Push back on scope creep
  • Scope is the boundaries that we as admins/consultants/developers are constrained to, typically tied to time and money
  • Allowing increases to the scope may put the project or release “at risk”
• Keep things as simple as you can - “Minimum Viable Product” in order to consider the project or release successful
• Share accountability - all the pressure should not be on the admins/developers
  • By writing good requirements and making sure that stakeholders agree to those requirements, you share accountability with the stakeholders by creating a common understanding
  • This way, later, they cannot come back and say that what you delivered is not “what they wanted”

Takeaways

• User stories very clearly define the who/what/why
  • If you’re not already using a requirements structure, experiment with it
• Consider who owns the business logic to determine when thinking about who to clarify requirements with
• Try building an app or tool in Salesforce to help manage requirements and acceptance criteria
  • The simple one demoed in the video had two objects related to each other:
    • Requirements and Acceptance Criteria
  • AppExchange provides many free/paid tools for this kind of thing
  • Jira or something similar would be a next, better step with more functionality
• Kanban and Scrum - methodologies to deliver smaller chunks more frequently to manage risk relating to shared understandings
  • Other agile methodologies are also available
• Should not be a “battle” between you and the stakeholders - you should be collaborators in a shared project