Salesforce Business Analyst cheat sheet

Discovery answers five core questions: who the users are, what they do today, where the pain is, what outcome defines success, and what constraints exist.

Stakeholder power/interest grid rules: high influence plus high interest = manage closely; high influence plus low interest = keep satisfied; low influence plus high interest = keep informed; low/low = monitor.

As-Is process maps document current steps, systems, handoffs, and cycle times; To-Be maps define the future Salesforce-enabled process and are the basis for gap analysis.

Personas capture role, goals, tasks, pain points, and system access; user stories are written using persona roles so requirements stay user-centered.

The 5 Whys continues until the answer identifies a process, data, or system cause; a person's name is a symptom, not a root cause.

Success criteria must state a baseline, a target, and a timeframe; 'improve user experience' is not measurable until it is quantified.

Customer journey maps record touchpoints, channels, actions, and emotions; moments of truth mark the highest-impact requirement areas.

An Art of the Possible demo uses standard Salesforce features to elicit ideas; it expands thinking but does not commit scope until requirements are prioritized and approved.

Discovery outputs typically include the current-state map, future-state map, gap list, prioritized pain points, and agreed success metrics.

RACI rules: exactly one person is Accountable per deliverable; Responsible does the work; Consulted gives input before the work; Informed is notified after.

A communication plan specifies audience, message, channel, frequency, owner, and feedback mechanism for each stakeholder group.

RAID log categories: Risks may occur, Assumptions are believed true without proof, Issues are already occurring, Dependencies are internal or external prerequisites.

Workshop flow: agenda, ground rules, parking lot for off-topic items, action items with owner and due date, and a written recap within 24 to 48 hours.

MoSCoW: Must = non-negotiable for this release; Should = important but a workaround exists; Could = nice to have; Won't = explicitly out of scope this time.

A decision log records decision, date, decision owner, options considered, and rationale, and is the reference when the same dispute resurfaces.

Sprint review demonstrates completed work to stakeholders and collects feedback; the retrospective focuses on improving team process.

Escalation thresholds and sponsor decision authority are agreed at kickoff so blockers reach the right decision maker without delay.

Stakeholder engagement levels move from unaware to resistant, neutral, supportive, and leading; the target level is defined per stakeholder.

User story format: As a [role], I want [capability], so that [benefit]; the benefit clause states the business value delivered.

INVEST criteria for user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable.

Acceptance criteria are testable pass/fail conditions; Given-When-Then expresses context, action, and expected result for each criterion.

Nonfunctional requirements cover performance, security, availability, scalability, usability, compliance, and data retention rather than feature behavior.

A traceability matrix links business objective to requirement to design element to test case; a requirement with no linked test case has no verified coverage.

Prioritization methods include MoSCoW, weighted scoring, and value-versus-effort; the prioritization criteria are agreed with the product owner before scoring.

Definition of Done applies to every increment the team delivers; acceptance criteria apply to one specific user story.

Prefer declarative configuration (point-and-click) over programmatic code unless platform limits are reached, because code raises maintenance and upgrade risk.

Ambiguous terms such as fast, user-friendly, flexible, and etc. are replaced with measurable thresholds or explicit lists.

BABOK knowledge areas: business analysis planning and monitoring, elicitation and collaboration, requirements life cycle management, strategy analysis, requirements analysis and design definition, and solution evaluation.

Typical sequence: plan the approach, elicit, analyze, document, validate, prioritize, baseline, support build and UAT, then evaluate the deployed solution.

Gap analysis compares current-state and future-state capability across people, process, technology, data, and policy.

Impact analysis covers users, processes, data, integrations, reports, security, training, and change management before a change is approved.

Requirements lifecycle: after requirements are baselined, changes enter formal change control with impact assessment and approval.

UAT is executed by business users against acceptance criteria in a full sandbox or staging environment; business sign-off is the gate before deployment.

Elicitation technique choice depends on stakeholder availability, geography, problem clarity, and whether consensus or individual detail is needed.

Solution evaluation measures post-go-live performance against the discovery success metrics to confirm benefits realization and identify follow-up work.

Business analysis planning defines scope, stakeholders, techniques, deliverables, and the review and approval process before elicitation begins.