Salesforce Business Analyst

A project built on the wrong problem fails however well it is delivered. You learn to draw out business goals and challenges, and turn them into a scope that everyone agrees on and can be held to.

• Business goals compared with business challenges
• Questions that reveal the real problem
• Writing a problem statement
• Setting scope boundaries and out-of-scope items
• Success measures the business accepts

You build A scope statement with goals, challenges and out-of-scope items for one project.

Before suggesting a solution, you must know how work happens today. You document the current state and match it against what Salesforce offers, so recommendations rest on evidence and fit.

• Documenting how work happens today
• Finding pain points and workarounds
• Overview of Salesforce capabilities by need
• Fit and gap thinking
• Recognizing when a need is not a Salesforce problem

You build A current-state summary with a fit-and-gap table against Salesforce capabilities.

Projects are won or lost on relationships. You identify who is affected, plan discovery around them, and build the kind of trust that makes people tell you what they really need.

• Identifying stakeholders and their stakes
• Influence and interest grids
• Planning discovery around stakeholders
• Becoming a trusted advisor
• Working with senior and reluctant stakeholders

You build A stakeholder map with a discovery plan for each group.

People rarely say what they need on the first ask. You learn how to run interviews, workshops, observation and document review, choose the technique that suits the stakeholder, and record what you learn without losing detail.

• Interviews that draw out detail
• Facilitating a requirements workshop
• Observing work in place
• Surveys and document analysis
• Choosing a technique for the situation
• Recording and confirming what you heard

You build An elicitation plan and notes from a mock stakeholder interview.

Stakeholders often want different things. You facilitate agreement on competing priorities, describe the future state in a form people can react to, and handle disagreements before they become rework.

• Surfacing competing priorities
• Facilitation techniques for agreement
• Negotiating trade-offs
• Describing the future state
• Documenting decisions and who made them

You build A future-state description with the decisions that led to it.

A process map shows where work stalls. You break complex processes into steps, document them in a way others can read, find where Salesforce could help, and keep the maps under version control as they change.

• Defining a process’s scope and boundaries
• Breaking a process into steps
• Swimlane diagrams and notation
• Finding pain points and improvement points
• Using the map to draw out requirements
• Version control for process documents

You build A current-state and future-state process map for one business process.

These three get confused, and the confusion causes disputes. You learn what separates scope, a requirement and a user story, and how to move from one to the next without losing meaning.

• Scope compared with requirements
• Business, functional and non-functional requirements
• Requirements compared with user stories
• Moving from need to requirement to story
• Spotting a requirement that is really a solution

You build A worked example that turns one business need into scope, requirements and stories.

Not every requirement can be built first. You check requirements with stakeholders for clarity and fit, prioritize them against value and effort, and keep a record of why each decision was made.

• Checking requirements for clarity and conflict
• Validating with stakeholders
• Prioritization methods such as MoSCoW
• Weighing value against effort
• Traceability from goal to requirement
• Handling changes to priority

You build A prioritized requirements list with the reasoning behind each ranking.

A good story is small enough to build and clear enough to test. You learn the parts of a user story, write stories from the user’s point of view, and split large ones so teams can deliver steadily.

• Parts of a user story
• Writing from the user’s point of view
• Good story qualities and common faults
• Splitting large stories
• Epics, themes and the backlog
• Keeping stories under version control

You build A set of user stories for one feature, each small enough to build in one cycle.

Acceptance criteria tell the team when a story is done. You write criteria that are specific and testable, handle edge cases and rules, and make sure developers and testers read them the same way.

• What acceptance criteria are for
• Writing testable, specific criteria
• Given, when, then style
• Covering rules and edge cases
• Checking criteria for readiness
• Keeping criteria in step with story changes

You build Acceptance criteria for five stories, checked for readiness by a mock developer review.

Your work does not stop at handover. You support the delivery team by answering questions, refining the backlog, reviewing demos against the criteria, and handling changes in a controlled way.

• Backlog refinement with the team
• Answering developer questions quickly
• Reviewing demos against criteria
• Managing change requests
• Keeping stakeholders informed during build

You build A backlog refinement session plan with a change request handling process.

Acceptance is where the business confirms the work. You plan user acceptance testing, write test cases from the criteria, manage defects, and gather sign-off that the solution meets the requirements.

• Planning user acceptance testing
• Test cases from acceptance criteria
• Preparing testers and test data
• Logging and triaging defects
• Validating against requirements
• Gathering sign-off

You build A user acceptance test plan with cases, defect process and sign-off steps.

Take one project from discovery to acceptance on paper. You scope it, map the process, write and prioritize requirements and stories, and plan acceptance, producing the package a delivery team would start from.

• Scoping the project and its stakeholders
• Mapping the process and drawing out requirements
• Writing and prioritizing stories
• Planning acceptance testing
• Presenting the package

You build A complete requirements package: scope, process map, stories, criteria and acceptance plan.