Publish date:

• 9th September, 2024

A Salesforce Business Analyst plays a vital role in bridging the gap between business teams and technical developers. They are responsible for overseeing the user experience (UX) and ensuring the platform meets business needs.

One of a Salesforce Business Analyst's primary tasks is to gather stakeholders' requirements about what they need from the system. This involves understanding future enhancements, improving the user experience, and driving adoption. The Business Analyst then translates these requirements into clear User Stories for the development team to work on. This guide outlines the best practices for Salesforce Business Analysts to follow.

In some organizations, the responsibilities of a Salesforce Business Analyst may overlap with those of a Salesforce System Administrator. However, it’s becoming more common for companies to have dedicated individuals in each role. These best practices are helpful for anyone handling Salesforce business analysis tasks.

Understand the Salesforce Current State

• Get Familiar with Your Organization’s Salesforce Front-End: One key responsibility of a Business Analyst is understanding who uses the Salesforce system, how they use it, and what roles or personas interact with the platform. It’s important to know which Salesforce Clouds (like Sales Cloud, Service Cloud, Marketing Cloud, Experience Cloud, etc.) are being used and which user groups rely on them.

• Leverage the Salesforce Optimizer: This built-in tool helps analyze the current usage of Salesforce. With the Optimizer, a Business Analyst can gather insights such as mobile usage and other key data. To access the Optimizer, go to Salesforce Setup and look for the Salesforce Setup Optimizer option.

• Conduct a Configuration Review: It’s a good idea to manually audit important settings such as Profiles, Permission Sets, Permission Set Groups, Page Layouts, Automation (like Flow), Sharing Settings, and Organization-Wide Defaults (OWD). This helps you understand how the backend of Salesforce is set up.

• Shadow Users: Spend time observing how different users in your organization interact with Salesforce. Take notes on what they do, their pain points, and areas they struggle with. Make sure to shadow users across different departments or roles to get a full picture of how the system is used.

• Document the Current State: Use a documentation tool of your choice to capture everything you learn about the current state of Salesforce.

Prerequisite for Being a Rockstar Salesforce BA

• Understanding Salesforce Capabilities: To be an effective Salesforce Business Analyst, it's essential to have a strong grasp of what Salesforce can do. If you're not yet a certified Salesforce Administrator or don’t have extensive experience with the platform, it's important to invest time in learning and improving your Salesforce skills.

Communicate With Stakeholders

• Identify Stakeholders and Build Relationships: A key responsibility for a Salesforce Business Analyst is identifying who the stakeholders are. These stakeholders can come from various teams like Sales, Service, and different levels of the organization, from VPs to team leaders. It's crucial to know who you're supporting.

• Build Trust: To succeed as a BA, building trust is essential. Be transparent, responsive, and open in your communication. Schedule one-on-one meetings with stakeholders, get to know their roles, and understand what they hope to achieve with Salesforce. If there are many stakeholders, it’s a good idea to create a stakeholder map.

• Schedule Regular Meetings: Set up regular meetings with stakeholders, possibly twice a week. Depending on the number of teams and projects you're handling, these meetings may need to be held separately for each group (Sales, Service, etc.). If meetings are remote, use video for better engagement. Invite the Product Owner to meetings that involve prioritization discussions.

• Set Up MS Teams/Slack Channels: Creating dedicated communication channels like MS Teams or Slack is a best practice. This allows easy communication with relevant stakeholders and makes it simple to share information and address questions. Set up different channels for different projects or departments to keep everyone in the loop.

Gather Stakeholder Requirements – Future State

• Understand the Desired Future State – Who, What, and Why: After identifying the right stakeholders for each part of the business, the Salesforce Business Analyst will start receiving enhancement requests. It’s the BA’s job to gather and clarify these requirements. This process involves understanding the "Who" (which users need something), the "What" (what exactly they need), and the "Why" (the reason behind the request). Gathering these details requires both skill and finesse.

Ask the Right Questions to Connect the Details

• Understanding the “What”: When stakeholders describe what they need, listen carefully and ask questions for clarity. If possible, ask them to show you what they mean in Salesforce. Requirements should be specific and measurable, not vague (e.g., avoid terms like “prettier”). Each request should be clear enough to explain in a single sentence.

• Understanding the “Why”: It's equally important to know why stakeholders need something. This understanding allows the Salesforce Business Analyst to guide them better and helps explain the reason for the request to the scrum team. Knowing the "why" improves the entire process.

• Identify “Must-Have” Features – The Minimum Viable Product (MVP): Not all features need to be delivered at once. Determine which ones are essential for the first release, and plan to add the rest in future iterations, aligning with Agile principles.

• Process Mapping/Prototyping: For large or complex requests, it’s a good idea to bring the right people together for a process mapping session. Map out the current process, suggest improvements, and get feedback. Always discuss the MVP, follow good design principles, and create wireframes if needed.

• Whiteboarding: Whether virtual or in-person, whiteboarding helps with brainstorming, listing out requirements, and visualizing process or data flows.

• Proof of Concepts in Salesforce: Using a developer’s org, BAs can configure Salesforce to create a proof of concept, showing how a requested enhancement will look and function.

• Final Thoughts on Priorities and Negotiation: For large projects, there’s often a need to negotiate what gets prioritized. Remind stakeholders that new features will be added regularly, so it's best to start with the most critical ones. It’s also helpful to add a quick, easy win when possible.

Understand the Key Principles of Agile Methodology

As a Salesforce Business Analyst, you will often work within an Agile framework, which is a flexible and collaborative approach to managing projects. Agile focuses on iterative development, teamwork, and continuous improvement. It's important to understand Agile methodology and its core principles to follow best practices effectively.

Key Principles of Agile

• Iterative Development/Incremental Delivery: In Agile, enhancements are delivered in small increments over time. These are completed in sprints, which typically last two to three weeks. At the end of each sprint, changes are tested in UAT and then released to production.

• Collaboration: Working closely with stakeholders, the Product Owner, and the Scrum Team is essential. Clear communication ensures everyone is aligned and working toward the same goals.

• Adaptability: Agile allows teams to adapt as priorities or requirements shift. Business Analysts and Product Owners can re-prioritize the backlog or even add urgent stories to the current sprint if necessary. While adding stories mid-sprint isn’t ideal and might frustrate the Scrum Master, it can be done by shifting some tasks to future sprints.

• Continuous Improvement: Agile focuses on making both the product and the team better over time. Each iteration should bring progress, with a constant drive toward improvement.

• Scrum Framework: It's crucial to understand Scrum, the most common Agile framework in the Salesforce ecosystem. Scrum operates with well-defined deliverables, timelines, and ceremonies like Daily Stand-ups, Sprint Planning, and Refinement sessions. Sprints have fixed durations, typically lasting a few weeks, and each ends with a release of completed work.

• Kanban Framework: Another Agile framework to know is Kanban, which visualizes work and limits the amount of work in progress. Kanban is often used by teams that have a steady flow of tasks, like an operations team. The use of a Kanban board helps track and manage ongoing tasks effectively.

Participate in Agile Ceremonies

• Quarterly Planning: It's a good practice for the BA to collaborate with the Product Owner and Stakeholders well in advance for quarterly planning. Start preparing weeks ahead by outlining Epics and User Stories, and placing them into upcoming Sprints in the Backlog.

• Daily Stand-Up: Attend the daily stand-up meeting on time, ready to answer any questions from the development team about the current sprint’s User Stories. Share any updates from the previous day and discuss any blockers you’ve encountered. This is also a good time to raise any issues with production or questions for the scrum team. Some organizations use a “parking lot” channel in Teams or Slack for additional discussions after the stand-up. If your team doesn’t have one, you might suggest it to your Scrum Master.

• Pre-Refinement: During pre-refinement sessions, the BA reviews the User Stories that have been written. This is the time to discuss the details of each story and consider potential solutions with Developers and Admins, focusing on the requirements. Make sure to mention any dependencies and mark them in the story.

Note: Not all stories require pre-refinement. Some are straightforward, but for those that need more discussion, it's important to review them with the scrum team.

While “solutioning” (the “how”) is usually the responsibility of the build team, the BA should still engage with the team for certain stories during pre-refinement. The BA understands what stakeholders ideally want and can suggest options that might be acceptable. If the BA has extensive Salesforce experience and understands its inner workings, they can offer valuable insights during the solutioning process.

• Refinement: During refinement, the BA reviews the User Stories planned for the next sprint. This involves explaining the “who,” “what,” and “why” of each story to the scrum team. Aim to be clear and provide a complete picture of what’s needed. Then, the team will assign story points. It's best for the BA to clearly define the scope of the User Story being discussed and list what is out of scope. This helps the scrum team assign more accurate story points.

• Sprint Planning: Before each Sprint begins, Sprint Planning takes place. The BA should ensure that all stories expected in the upcoming sprint are story-pointed and assigned to the correct sprint. During the meeting, the BA can clarify any questions about the stories. While assigning the build for a story is generally handled by the scrum master and developers, the BA can suggest who might be best suited for a particular task if they have relevant experience. After stories are assigned, the BA should offer to discuss the User Story with the builder to ensure clarity and offer to review the build once it’s in progress.

• Sprint Demo: At the end of each sprint, the BA should demo the new features to stakeholders. This helps keep everyone informed and allows for immediate feedback.

• Release Management/Change Management: For each release to Production, create a list of User Stories that were deployed, including screenshots to highlight changes, and share this with stakeholders. After deployment, the BA should conduct a Production Validation to confirm that the stories have been successfully implemented.

• Retrospective: After each sprint, a retrospective meeting is held (often a few days later). The BA should discuss what went well and identify areas for improvement for the next sprint. It’s also a good practice to acknowledge and thank team members who were particularly helpful. This fosters continuous improvement.

Skill-Up on User Story Writing and Acceptance Criteria

User Stories are essential for capturing stakeholder requests for Salesforce enhancements. Here’s how to write effective User Stories:

• General Guidelines: User Stories should be independent, valuable, small, testable, and detailed enough to estimate the work involved. They are usually grouped into Epics.

• Title: Use a clear, descriptive title that summarizes the User Story. For example: “Enhance Account Layout with a Related List Showing ‘Past Products Purchased’.”

• Body: Start with the User Story statement: “As an X (the ‘who’), I want Y (the ‘what’), so that Z will happen (the ‘why’).” If the story involves multiple scenarios, include several statements.

• The What and Why: To help the scrum team understand the User Story, clearly explain “what” the story is about and “why” the enhancement is needed. Use bullet points or a paragraph in the top section of the User Story to provide this information. Adding screengrabs or mockups can also be helpful.

• Acceptance Criteria: Each company may have its preferred format for Acceptance Criteria, but it should always include what the Testing Team needs to test and how to test it. Specify which Users are affected, what to test, and what the expected results should be.

• Given, When, Then (GWT): Many teams find the GWT format useful for Acceptance Criteria. It’s straightforward and appreciated by builders and testers. Each scenario should have its own 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 on any Account record
THEN: I will see an Account record with a Related List called “Past Products Purchased” placed directly below the “Opportunity” Related List. The fields in this new Related List will include: Product Name, Date Purchased, Quantity Purchased.

Note: The GIVEN describes the setup and who is affected, the WHEN describes the action, and the THEN outlines what the user will see or experience.

• Final Tips: If a stakeholder request is complex, break the User Story into smaller stories and link them together (e.g., in Jira). Each User Story should be small and testable. If a User Story is too lengthy or complex and gets a high story point estimate, consider dividing it into smaller parts or creating a Research Spike to gather more information first.

A memorable moment I recall: A senior developer once joked during refinement that a long User Story required three points just to review! Long, complicated User Stories are considered an “anti-pattern” (a term used in Agile to describe something not recommended).

Lastly, do your research and discussions with stakeholders at the start of the sprint or in a prior sprint. This will give you enough time to write up the User Story and discuss it during pre-refinement and refinement.

Assist with QA and UAT Testing

• QA Review: To ensure the quality of a User Story, it’s best practice for a Business Analyst (BA) to review the build once it reaches the QA environment—or even earlier in a developer’s sandbox. This proactive step helps identify and fix issues before the User Story is reviewed by the testing team or stakeholders.

• UAT Testing: After a User Story is deployed to the UAT (User Acceptance Testing) environment, the testing team will use the scenarios outlined in the Acceptance Criteria to thoroughly test it. The BA should also review the changes in UAT. Once everything looks correct and the testing team approves, the BA should notify stakeholders for their review and approval before the User Story goes live in Production.

Conduct User Training and Prepare Communication Summaries

• Prepare Training Materials: Before each release to Production, it’s important for a Business Analyst (BA) to create Training Materials for Users. These materials should include screenshots of each User Story and clear explanations of new features and what is expected from Users.

• Conduct User Training: It’s a best practice for the BA to conduct training sessions for all new features after each release. The training should be engaging and informative, telling a clear story. At a minimum, ensure stakeholders are well-trained.

• Prepare Communication Summaries: The BA should also prepare Communication Summaries to inform management. These summaries can be added to the end of each User Story and should include a brief description of the enhancement, focusing on its benefits, along with a screenshot or two.

Develop Key Reports, Dashboards, and List Views

• Create Key Reports: It’s a best practice for a Business Analyst (BA) to collaborate with stakeholders to develop valuable reports that help track business success. Focus on creating reports for Opportunities, Cases, and other relevant objects. These reports should include essential metrics like record Owner, Stage, and other key details.

• Create Key Dashboards: After creating reports, the BA should build Dashboards for Stakeholders. Dashboards are great for visualizing data and now offer up to five filters. For example, in a Sales Dashboard, you could include numerous sales reports and charts with filters such as Opportunity Owner, Stage, Close Date, Create Date, and Amount. Additionally, you can use relative date ranges like "Previous 30 days," "This week," "Next 30 days," or "This Year."

Make sure to train stakeholders and users on how to use these dashboards effectively. Sales Managers often find dashboards helpful for understanding their pipeline and drilling down by factors like Opportunity Owner or upcoming deadlines. Also, restrict who can edit key dashboards while allowing users to clone them for their own needs.

• Create List Views: List Views are another essential tool that helps users quickly access relevant records. Work with stakeholders to determine which fields should be included in these views and filter them to show only the most important records, like by Record Type or other criteria. Limit who can modify key List Views to maintain consistency.

• Key List Views: For Opportunities, consider creating List Views such as "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," and "Opportunities Scheduled to Close in the Next 30 Days."

Understand Jira, ADO, and Other Tools of theTrade

• Jira: Jira is a powerful project management tool created by Atlassian. It’s particularly useful for Agile teams. With Jira, you can create Epics, which represent larger projects, and break them down into User Stories. Jira also tracks other items like Sub-tasks, Bugs, and more. Sometimes, Epics can be grouped under "Initiatives" for better organization and cost management, as seen in some companies where the CFO wanted to amortize costs for major projects.

• Assignments: In Jira, every User Story should be assigned to someone to ensure it doesn’t get overlooked. It’s a best practice for the Business Analyst (BA) to handle the assignment while writing up the User Story. Once the User Story moves to Sprint Planning, the assignment should change to the builder or developer who will be working on it.

• Stage: User Stories in Jira should have a Stage, which the scrum team defines. Typical stages might include "Not Started," "In Analysis," "Analysis Complete," "Ready for Development," "In Development," "Ready for Testing," and "Deployed to Production."

• ADO: Azure DevOps (ADO) is another popular tool similar to Jira, developed by Microsoft. It offers similar features for project management and tracking.

• Lucid Charts, Miro Boards, Figma, Excel: These tools are excellent for creating visualizations, workflows, dataflows, and wireframes. Get to know the tools your organization uses to effectively communicate and document your projects.

Summary

The Salesforce Business Analyst (BA) plays a crucial role in bridging the gap between stakeholder needs and the build team. By translating stakeholder requirements into clear User Stories, the BA ensures that the development team can deliver effective solutions. Following the best practices outlined above helps guarantee a seamless and successful user experience.

Ready to elevate your Salesforce projects? At Codleo Consulting, a leading Salesforce consulting firm, our experienced Salesforce consultants are here to guide you through the best practices that will streamline your processes and maximize your success. Discover how our tailored solutions can transform your Salesforce experience. Contact us today to learn more!