Business Analysts / Consultants

10 Best Practices for a Salesforce Business Analyst

By Jeff Nesler

The Salesforce Business Analyst has a unique and critical role in any organization – because the business analyst sits between business stakeholders and technical builders, and will govern the user experience (UX).  

The BA has many responsibilities, one of the main ones being to elicit requirements from stakeholders regarding the desired future state for enhancements, user experience, and adoption. The BA then needs to translate those requirements into User Stories for the build team to deliver. This guide provides best practices for the Salesforce Business Analyst.

Before I continue, I want to highlight that depending on the organization, the duties of the Salesforce Business Analyst are sometimes performed by the Salesforce System Administrator. This is less common now, as more and more organizations have separate individuals doing system administration and business analysis. That said, these best practices apply to anyone carrying out the functions of the Salesforce Business Analyst.

1. Understand the Salesforce Current State

  • Learn the Front-End of Your Organization’s Salesforce Instance: A best practice of the BA is to learn who uses the Salesforce system, how they use the system, and the different personas who utilize Salesforce.  The BA should also know which Salesforce Clouds are being used in the org (Sales Cloud, Service Cloud, Marketing Cloud, Experience Cloud, other), and by which user groups.
  • Use the Salesforce Optimizer: This native tool can assist with current state analysis. With Optimizer, the BA can view usage information, for example, such as Mobile Users, plus other information. To get to the Optimizer, go to Salesforce Setup [Salesforce Setup Optimizer].
  • Conduct a Configuration Audit: To become familiar with the organization’s back-end setup, it’s a best practice to manually review Profiles, Permission Sets, Permission Set Groups, Page Layouts, Automations (Flow, etc.), Sharing Settings, and OWD.
  • Shadow Users: Observe how Users interact with Salesforce for their day-to-day job, and take notes. Understand what they do in Salesforce, and what their pain points are. Try to shadow Users in different roles in the organization. 
  • Document Current State: Use a tool of your choice.

Prerequisite for Being a Rockstar Salesforce BA

  • The Need to Understand Salesforce Capabilities: If the BA is not a Certified Salesforce Admin, nor has years of experience with Salesforce, the BA should skill up.
READ MORE: 5 Salesforce Tools That Every Business Analyst Should Use

2. Communicate With Stakeholders

  • Document Who the Stakeholders Are and Develop Relationships: First off, the BA needs to be told/or figure out who all the stakeholders are that the BA is supporting. Often there will be stakeholders from a variety of groups, like Sales and Service, plus stakeholders at different levels of the business, such as the VP of a department or a team leader in the trenches. 
  • Build Trust: A best practice for the BA is to build trust with stakeholders, by being transparent and responsive. Develop open communications, and schedule one-on-one time with each of the stakeholders. Become familiar with each stakeholder’s role in the organization, and what benefits they want to get from Salesforce. The BA should create a stakeholder map if there are many stakeholders.
  • Schedule Recurring Meetings with Stakeholders: Depending on how many different teams or projects the BA is supporting, these might be separate meetings for different groups of stakeholders (i.e., Sales, Service, etc.). Meeting at least twice a week is a best practice. Use video for remote meetings, not just audio. Invite the Product Owner to recurring meetings where prioritization is being discussed.
  • Setup MS Teams/Slack Channels with Stakeholders: Setting up these channels is a best practice and will allow for communications to groups where information and questions can be shared. The BA will likely need to set up multiple channels based on who needs to be in the loop for different departments or projects. 

3. Gather Stakeholder Requirements – Future State

  • Understand Desired Future State – the Who, What, and Why: Once the BA determines who the correct stakeholders are for different areas of the business, the stakeholders will have enhancement requests, which will necessitate the business analyst to elicit requirements. Gathering these requirements is both a skill and an art, with the goal of determining the “Who” (which Users need something), the “What” (what do they need), and the “Why” (for what reason is this being requested).

Ask the Right Questions to Connect the Details

  • Understanding the “What”: Have the business stakeholders explain what they are looking for and listen carefully, asking questions for clarity. Have them show you in Salesforce, if possible.  Requirements should be measurable (i.e., not “prettier”). Each requirement should be able to be described in a sentence. 
  • Understanding the “Why”: Have the business stakeholders explain why they need what they are asking for. This is important because if the business analyst understands why something is being requested, they can better assist with all aspects of the request. This includes providing guidance to Stakeholders, and explaining to the scrum team why something is being requested.
  • Need to Determine Which Features Are “Must Have Now” – the Minimal Viable Product (MVP): Many features can and should be added in later iterations. This is one of the key principles of Agile, discussed in the sections below.
  • Process Mapping/Prototyping: For large or complex enhancement requests, best practices include: setting up a meeting with the right people in the room for a process mapping working session, developing the process map based on the needs of the business, developing new/better steps, be clear, and get feedback. Discuss the MVP. Use good design patterns, and create wireframes.
  • Whiteboarding: Either virtual board or in-person. This is helpful for brainstorming, listing requirements, or visualizing steps in a process or data flow.
  • Could Develop POCs Directly in Salesforce: BAs can use a developer’s org and configure Salesforce to show how certain enhancements would look and function.   
  • A Final Thought About What Is Really Needed or Negotiable: There is typically a negotiation of sorts regarding priorities, especially when a project is large. Remind stakeholders that the team will add features every few weeks, so bite off the most important items first. It also doesn’t hurt to add an easy quick win. 
READ MORE: The Business Analyst’s Guide to Good Documentation

4. Understand the Key Principles of “Agile” Methodology

The BA will often be working within an “Agile” framework, which is a methodology for managing projects that emphasizes flexibility, iterative development, collaboration, and continuous improvement. Best practice for a BA is to learn Agile methodology and follow its key principles.

Key Principles of Agile

  • Iterative Development/Incremental Delivery: The best practice is to add incremental enhancements during each sprint (which often start and end every two or three weeks), culminating with a release to Production from UAT at the end of each Sprint.
  • Collaboration: With Stakeholders, Product Owner, and Scrum Team. Everyone should be on the same page.
  • Adaptability: As requirements or priorities change, Agile can adapt and Product Owners/Business Analysts can re-prioritize the backlog (or even add stories to the current sprint, if urgent). Of course, it’s not a best practice to add stories mid-sprint, but it’s possible. I assure you the Scrum Master won’t be thrilled, and this may require moving one or more stories from the current sprint to a future sprint.
  • Continuous Improvement: The team and product are always getting better. “Getting better all the time” (The Beatles).
  • Scrum: The best practice is for BA to understand Scrum, as Scrum is the most popular Agile framework in the Salesforce ecosystem, with well-defined deliverables and timelines. It uses fixed-length iterations called Sprints, plus has defined roles and ceremonies such as a Daily Stand-up Meeting, Refinement, and Sprint Planning (see ceremonies in next section). This is the framework I’ve been a part of at multiple organizations over the years.
  • Kanban: This is another Agile framework to be aware of, which focuses on visualizing work and limiting work in progress. It also uses a Kanban board to track issues. I’ve seen this framework being used by some teams, as it has its use cases, such as an Operations team that has a steady, continuous flow of work.

5. Participate in Agile Ceremonies

  • Quarterly Planning: The BA should work with the Product Owner and Stakeholders to prepare early for quarterly planning, ideally weeks in advance. The team should begin to “stub out” Epics and User Stories, and place them into future Sprints in the Backlog.
  • Daily Stand-Up: Come to daily standup meeting on time, prepared to answer questions the build team has regarding stories in the current sprint. Mention other key items from the previous day, and discuss any blockers. This is also a good time to bring up production bugs or questions for the scrum team. Some organizations have a helpful Teams/Slack channel called the “parking lot” for the end of daily standup, for those extra items to discuss with the team. Ask your Scrum Master about adding one!
  • Pre-Refinement: During pre-refinement, the BA will review the User Stories they’ve begun to write up. This is a good time for the BA to discuss the details of the story and possibly discuss solution options with the Developers and Admins, focusing on the requirements. The BA should also bring up any dependencies during pre-refinement and code them on the story.

Note: Not all stories require pre-refinement (as some stories are straightforward). The BA should review stories with the scrum team that warrant discussion.   

While “solutioning” (the “how”) should generally be left to the build team, in my experience the BA should discuss with the build team for certain stories during pre-refinement, as the BA knows what the stakeholders ideally want, or options that would likely be acceptable to stakeholders. If the BA happens to have years of Salesforce experience and knows the plumbing of Salesforce, the BA is in a unique position to add value to the solutioning conversation.  

  • Refinement: This is where the BA typically reads through the User Stories planned for the next sprint (explaining the “who”, “what”, and “why” to the scrum team). Try to be clear and paint a picture of what is needed. Then story pointing happens.  A best practice is for the BA to properly box the scope of the work being done for the User Story being discussed (and list what is out of scope), so story pointing by the scrum team can be more accurate. 
  • Sprint Planning: Before each Sprint begins, there is Sprint Planning.  Prior to Sprint Planning, best practice for the BA is to make sure all the stories the Product Owner, Stakeholders, and the BA expect to be in the upcoming sprint are story-pointed and coded to the proper sprint. During Sprint Planning, if there are any questions about stories, the BA can clarify.  Regarding who gets assigned the build for a story, this is generally left up to the scrum master and admins/developers, but the BA could opine if a certain builder has been working on something or has bespoke knowledge. Finally, after the stories have been assigned to a builder during sprint planning, the BA should offer to discuss the User Story/Build with them to make sure there is clarity, and offer to view the build once it’s in progress.  
  • Sprint Demo: At the end of each sprint, it is a best practice for the BA to demo the deployed features to stakeholders.
  • Release Management/Change Management: The best practice for each release to Production is to put together a list of User Stories that deployed to Production, with screengrabs to show changes – and distribute this to stakeholders. After the stories have been deployed to Production, the BA should also do a Production Validation, to make sure the stories deployed. 
  • Retrospective: At the end of each sprint (or often a couple of days after the sprint ends), the retro takes place. The best practice for the BA is to point out what went well, and what could be improved for the next sprint. Finally, it’s always nice to give kudos to someone who was particularly helpful during the sprint. Continuous improvement!
READ MORE: Agile Development with Salesforce

6. Skill-Up on User Story Writing and Acceptance Criteria

These are essentially the requests of the stakeholders for enhancements to Salesforce.  Here are some best practices for successful User Story writing.

  • General Rules: User Stories should be independent, valuable, small, testable, and with enough detail to estimate the work effort to build.  User Stories are generally grouped by Epic.
  • Title: The best practice is to use a descriptive title for the User Story that indicates what the story is about at a high level. For example: “Enhance Account Layout with a Related List Showing ‘Past Products Purchased’.”
  • Body: Begin with the User Story statement: “As an X (the ‘who”), I want Y (the ‘what’), so that Z will occur (part of the ‘why’). You may need multiple statements if the User Story has multiple related scenarios. 
  • The What and Why: To help the scrum team understand “what” the User Story is about, and “why” this enhancement is being requested (and what problem it is solving). It is a best practice to list bullet points/or write a paragraph to succinctly explain this information in the top section of the User Story. A best practice is to include screengrabs/mockups in the User Story, using arrows and text boxes to show the requested enhancement. 
  • Acceptance Criteria: Each company I’ve worked at has different preferred ways to write out the Acceptance Criteria, but in all cases the A/C should include what the Testing Team would need to test, and how to test (for each scenario). The BA will need to include which Users each enhancement affects (by profile or other criteria), what specifically to test, and what the expected outcome will be.
  • Given, When, Then (GWT): In the last organization I worked at, they preferred the A/C to be provided in the GWT format. I now really like this format and builders and testers seem to appreciate its simplicity. Each scenario would require a separate GWT. Here’s an example:

Scenario: Sales User can View ‘Past Products Purchased’ on Account record
GIVEN: I am a Sales User with Profile=Sales AND Role=Product Sales
WHEN: I select the Accounts tab AND click through to any Account record
THEN: I will see an Account record with a Related List called “Past Products Purchased” AND this Related list will be placed directly below the “Opportunity” Rel. List. AND the fields displayed in the new Related List will include, in this order: Product Name, Date Purchased, Quantity Purchased

Note: The GIVEN is the setup of the situation (and who is affected), the “WHEN” is typically an action, and the “THEN” signifies what the user will encounter after the “When” occurs. Give it a try!

  • Final Notes on User Stories: If a stakeholder request has a lot going on, it is recommended to break the User Story into multiple stories (and link the stories together in Jira, for example). Remember, each User Story should be small and testable. If a long, complicated User Story is being discussed/pointed during refinement, and people are suggesting 8 or 13 story points, the story can likely be broken down into smaller chunks (or the team could create a Research Spike, if more information needs to be gathered first). 

I recall a senior developer once making a joke during refinement for a long, complex User Story that a BA was reviewing with the scrum team – and the developer declared, “We need three points just to review the User Story.” LOL. Long/complicated User Stories are an “anti-pattern” (which is my favorite Agile Term; it’s a polite way to say “not recommended” or “bad idea”). 

A final best practice for writing User Stories is to do the research/discussions with stakeholders at the beginning of the sprint, or in a previous sprint, so the BA will have enough time to write up the story and discuss it during pre-refinement/refinement. 

READ MORE: How to Write User Stories for Salesforce: What We Learned From Writing 1000

7. Assist with QA and UAT Testing

  • QA Review: As a proactive BA, a best practice is to review the build of a User Story once it hits the QA environment (or even before, in a developer’s sandbox), instead of waiting for the User Story to be deployed to the UAT environment. This will ensure the User Story is correct before the testing team or stakeholders review it.
  • UAT Testing: Once a story has been deployed to the UAT environment, this is typically where the testing team will thoroughly test using the testing scenarios in the Acceptance Criteria. A best practice of the BA is to review the changes in UAT also, and once it looks correct and the testing team has signed off, the BA should communicate to the stakeholders to review and approve, before it deploys to Production.

8. Conduct User Training and Prepare Communication Summaries

  • Prepare Training Materials: Before each release to Production, a best practice for the BA is to put together Training Materials for Users. These training materials would include screengrabs for each User Story and explanations of what’s new and what’s expected of Users.
  • Conduct User Training: Another best practice is to conduct User Training for all new features. This can be done after each release. Training should tell a story. At a minimum, the BA should train the stakeholders.
  • Prepare Communication Summaries: A part of the BA best practices is to help communicate to management by preparing Comm Summaries. These could be added to the bottom of each User Story, and should include a short description of the enhancement being deployed, focusing on benefits, plus a screengrab or two.

9. Develop Key Reports, Dashboards, and List Views

  • Create Key Reports: A best practice for an effective BA is to work with stakeholders to prepare meaningful reports, which will help the business measure success. The BA should create reports for Opportunities, Cases, and other objects the business uses. These reports could include the Owner of the records, Stage, and other useful metrics.
READ MORE: 10 Advanced Salesforce Reporting Features
  • Create Key Dashboards: Once the Reports are created, the BA should also create Dashboards for Stakeholders. One thing I love about dashboards is the ability to filter Dashboard Reports – and Salesforce has upped the number of Dashboard Filters from 3 to 5. For example, if creating a Sales Dashboard, you could include 10+ different sales reports and charts, and then add Dashboard Filters, that could include, for example: Opportunity Owner, Stage, Close Date, Create Date, and Amount.  Further, within the Dashboard filters – you can include relative date ranges, like “Previous 30 days”, “This week”, “Next 30 days” or “This Year”.  

Finally, don’t forget to train stakeholders and other users on the dashboards and how they work. Sales Managers will typically love to see a dashboard like this, as they can better understand their pipeline, and then drill down by Opportunity Owner, Next 30 days, etc. Also, I recommend restricting access to who can “Edit” the key dashboards. A User can still Clone a dashboard for their unique purposes.  

READ MORE: 10+ Salesforce Dashboard Tips & Tricks
  • Create List Views: An often-overlooked best practice is to create meaningful List Views for all key objects. List Views are so valuable to Users, and the BA can filter the List Views to only show relevant records (such as by a Record Type or other criteria). The BA should work with stakeholders to identify which fields the List Views should contain. Again, I recommend restricting who can change the key list views.  
  • Key List Views: For example, for Opportunities, some List Views could include: “All Open Sales Opportunities”, “New Sales Opportunities created in Last 7 days”, “Closed-Won Opportunities This Month”, “Closed-Lost Opportunities”, “Open Sales Opportunities with Amount > $50,000”, “Opportunities scheduled to close in the next 30 days”, etc.

10. Understand Jira, ADO, and Other Tools of the Trade

  • Jira: One of my favorite tools for Agile is Jira, which is a tool created by the company called Atlassian. This web-based tool can be used as a project management tool, which allows an organization to create Epics (which are the names of larger projects), and then under each Epic, the BA creates User Stories. Jira can also track other types of items too, like Sub-tasks, Bugs, and more. (Note that Epics could be grouped together under “Initiatives”. At one company I worked at, we grouped a bunch of Epics under an Initiative, as the CFO wanted to amortize costs for a major project). 
  • Assignments: Each User Story in Jira should always be “Assigned” to someone, so it doesn’t slip between the cracks. A best practice is for the BA to be assigned to the User Story while it is being written up – until it has been assigned in Sprint Planning, at which point the assigned person would change to the builder/developer. 
  • Stage: All User Stories in Jira also should have a Stage, and these stages are defined by the scrum team. Some stages could include “Not Started”, “In Analysis”, “Analysis Complete”, “Ready for Development”, “In Development”, “Ready for Testing”, “Deployed to Prod”, etc.
  • ADO: this refers to Azure DevOps (a Microsoft product), and this is also a popular tool that has similar features as Jira. 
  • Lucid Charts, Miro Boards, Figma, Excel: Each of these tools allows the BA to create visualizations, workflows, dataflows, and wireframes. Become familiar with the tools your organization uses!
READ MORE: What is a Salesforce Business Analyst – How Do You Become One?

Summary

The role of the Salesforce BA is critical because the BA needs to translate what the stakeholders want into User Stories that the build team can create. It’s important to follow the above best practices to ensure a fantastic user experience. 

Any questions? Ask the stakeholders for clarification!

The Author

Jeff Nesler

Jeff began working in the Salesforce ecosystem in 2004, and he has helped a variety of organizations transform their businesses.

Leave a Reply