Propel your Career with Business Analysis
Earning the Certified Salesforce BA Credential
Salesforce communities have been buzzing about the new Certified Salesforce Business Analyst credential. Unlike technical certifications, 50% of the business analyst credential exam covers soft skills such as building relationships, trust, and influence.
How does one prepare for the Certified Salesforce Business Analyst exam? Vanessa Grant, Janeen Marquardt, and I offered some answers at Tahoe Dreamin’ 2022. We presented an overview of each of the six exam topics, along with some tips on how the topic applies in practice. The sections below summarize what we covered.
Customer Discovery
Discovery gets to the heart of your customer’s business, their pain points, and the problems they are trying to solve. It starts with understanding the five most important elements of the business as expressed in Peter Drucker’s five questions:
What is the purpose of the business?
Who are the customers?
What do the customers value?
What are our results?
What is the plan?
The purpose of most businesses, in providing the primary good or service, is to deliver value to their customers. The company can evaluate how well it meets that goal with key performance indicators (KPIs) or success metrics.
Janeen pointed out that discovery skills are among the basic building blocks of any customer-facing career:
Eliciting information, sometimes sensitive
Communicating clearly
Grasping complex concepts quickly
Synthesizing large amounts of information
Building trust
She offered an example of a job interview: you aren't just answering questions; you should also ask the right questions to ensure the opportunity is a good fit for you. Those questions include the company’s purpose, values, and plans.
Collaboration with Stakeholders
Collaboration is the heart of effective business analysis:
Engage the right stakeholders
Empathize with their challenges
Align stakeholders to solution benefits and objectives
Develop trust through respect and appreciation
For example, Janeen’s company holds collaboration and trust among its core values. She emphasized that these values are critical to success in any role, not just business analyst.
Business Process Mapping
Vanessa introduced business process mapping with a model activity box from Universal Process Notation (UPN):
Business process maps make understanding and communicating processes much easier among teams, stakeholders, or customers. They also help identify flaws in the process and areas for improvement.
Vanessa offered some reasons to create a business process map:
A visual project to get everyone on the same page
See current state vs. future state
Identify waste such as obsolete processes
Requirements
I define requirements as:
Measurable and verifiable business needs
Elicited from business stakeholders
Should reflect the current state as well as the future state
Should be recorded in a version-controlled repository
Contain user stories
Business analysts elicit what businesses need, including needs already met - the current state. The future state encompasses the solution under development. Then, business analysts curate the needs into requirements and record them in a version-controlled repository, enabling multiple stakeholders to edit the same requirement without overwriting their changes.
In practice,
Discovery yields pain points, wish lists, and feature requests
Keep requirements focused on specific business outcomes
Avoid jumping into features before finishing requirements
While business analysts should capture and acknowledge every pain point, wish list, and feature request, they should focus on business outcomes within the current solution version’s scope. They should resist the common temptation to jump into feature specifications, leaving the requirements incomplete or unfinished - the leading cause of software project failures.
User Stories
Vanessa started with the user story template:
As a < who >,
I want < what >
so that < why >
Where <who> is a persona and the <what> is a task they need to accomplish to fulfill a purpose - the <why>.
For 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.
Vanessa also discussed user story acceptance. A user story cannot be ambiguous - the acceptance criteria must be true or false. A user story should also avoid specific solutions like this:
As a Sales Manager, when I click on the “Opportunities by Region” button, I can see all open Opportunities by region…
No business tries to achieve a button - the story should point toward a sales goal.
Vanessa stressed understanding the difference between:
User stories
Acceptance criteria
Requirements
Definition of done
The Trailhead “Scrum and Kanban at Salesforce” module touches on the definition of done.
Most importantly, the business stakeholders and the development team should understand the user stories.
User Acceptance
User acceptance testing (UAT) checks a solution against its requirements
Business analysts drive UAT planning and execution
Most familiar with requirements, business stakeholders, and their terminology
UAT fails when it reveals gaps or mismatches between a solution and its requirements
User acceptance testing is different from software testing. The testers are not looking for bugs; they ensure the solution will do what their organization needs, as specified by the requirements.
Business analysts should drive UAT planning and execution because they know the requirements and stakeholders best. Also, UAT shows them how well they did discovering and developing requirements.
In practice,
Find users familiar with their process to run acceptance tests
Write test scripts with these users and their workflow in mind
Encourage testers to go off-script in realistic scenarios
Track every difference between testers’ experience vs. expectations
Learn from the differences to improve future analysis
Business analysts should find users familiar with the process to verify and willing to invest their energy into ensuring the solution meets the organization’s needs. Also, business analysts should create step-by-step test scripts for these users using business terminology. Testing users can go off-script to check how the solution behaves when someone uses it in unexpected ways, within reason.
Business analysts should keep track of any discrepancies between solution behavior and what the testers and stakeholders expect from it. Then, they can learn from these discrepancies to improve requirements elicitation and understanding in the future.
Clarifying the Concepts
We concluded with a concept map of the business analyst’s journey based on the certification exam topics.
The journey starts with discovery, collaborating with stakeholders to produce requirements, process maps, and user stories. Then, the development team takes this information, along with UX design, to build a well-tested solution. Finally, qualified users test the solution and accept it if it fulfills the requirements.
Both discovery and user acceptance depend on extensive stakeholder collaboration to cover the requirements accurately. These conversations should focus on business outcomes instead of solution features. Respecting and appreciating stakeholders’ time and energy builds trust, an essential ingredient of business analysis success.
Business analysis skills covered in the Certified Salesforce Business Analyst will propel your career forward as you learn how to discover and fulfill business needs.
Looking for more information about the Certified Salesforce Business Analyst credential? Check out The Salesforce Certified Business Analyst Credential section of Business Analysis Knowledge for Salesforce Experts, Fifth Edition.