Writing Salesforce User Stories: Template, Examples & Acceptance Criteria

Hey friends,

A Salesforce user story is a one-sentence description of a feature from the user's point of view, written as "As a [who], I want [what] so that [why]", plus acceptance criteria: short pass/fail statements that say when the story is done. Get those two parts right and your admins and developers build the right thing the first time, and your testers know exactly what to check.

This post walks through the format, how to write acceptance criteria, the INVEST checklist and the mistakes I see most. It's based on Trailhead's User Story Creation module and the Business Analyst cert prep unit on user stories. User Stories is 18% of the Salesforce Business Analyst exam, so this is also core exam material.

What are the three parts of a user story?

• Who: the user persona. "A service rep", "a district sales manager". Not "a user".
• What: the goal they want to accomplish in Salesforce.
• Why: the business reason. This is the part people skip, and it's the part that lets the team pick the best solution.

Trailhead's own 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.

Notice what's missing: no mention of queues, Omni-Channel, page layouts or buttons. A user story describes the need. How it gets built is decided later, by the people building it.

How do you write acceptance criteria?

Acceptance criteria are a set of statements, each with a clear pass or fail result, that define when the story is fulfilled. Three rules cover most of it:

1. Every story has at least one. No criteria, no way to say it's done.
2. Each one is independently testable and answers true or false.
3. State intent, not a solution. Describe the what, not the how.

Trailhead's intent-versus-solution example is worth memorizing:

For the case story above, good criteria are: take ownership of cases from the queue; email customers from the case page; update case status, subject and description. You can also write them as if/then statements: If on a case page, then the email customer feature is accessible.

What do good Salesforce user stories look like?

Here are four I'd accept in a backlog, with criteria. Each one has a real persona, a single goal and a reason.

Notice the 20% story: it includes the boundary (exactly 20%), because boundaries are where testers find bugs.

Quick backstory. When I studied for my first certs, Focus on Force was my favorite resource, and what made me learn fastest was rapid-fire practice tests: take a quiz, read why each miss was wrong, go again. I built Cert Lab around that loop, with current Help links and screenshots in the explanations. Certs have brought me interviews, a new job, raises and a way into new parts of the platform. They don't replace experience, though. The cert gets you the conversation; what you've built closes it.

How do you know a user story is good enough?

Run it through INVEST. If it fails one check, it probably needs a rewrite.

If a story isn't Small or Estimable, split it before it goes to sprint planning. New to sprints? My agile basics for Salesforce projects post covers how Scrum and Kanban work.

My most-used check is Small. "As a rep, I want a better opportunity page" is an epic, not a story. Split it into stories you can finish and test inside one sprint.

What mistakes should you avoid?

These come straight from the Construct a User Story unit, and I've seen every one on real projects:

• The team didn't help write it. Hold a story-writing workshop near the start of the project with product owners, admins, developers, designers and users.
• The who is undefined. Build a persona list first and reuse it.
• The why is feature-specific. "So that the field is required" is not a reason. "So that billing never gets an order without a PO number" is.
• The criteria are vague. "Works well on mobile" can't pass or fail.
• It was handed off without a conversation. Review stories with the team when you assign them.

What's the difference between acceptance criteria and definition of done?

Acceptance criteria belong to one story and say what that story must do. The definition of done is agreed by the team and applies to every story, things like "tested in a sandbox", "peer reviewed", "release notes updated". A story is finished only when it meets both. The BA exam's User Stories section lists both topics, along with sign-offs, testing and keeping stories in a version-controlled repository.

Where should user stories live?

In one shared, version-controlled place the whole team uses, not in someone's inbox. That might be your agile tool, a Salesforce-based backlog or a repository, as long as there's history: who changed the story, when, and why. That history is what protects scope when a stakeholder says "but we agreed on something else".

If you learn best by testing yourself, the Business Analyst Cert Lab is built for that: short quizzes, then explanations for every option.

FAQ

Is a user story the same as a requirement?

No. A requirement states what the system must do. A user story is a short, user-centered summary of a need that invites a conversation; it doesn't spell out the whole requirement. Understanding scope vs requirements vs user stories is an exam objective.

How many acceptance criteria should a story have?

At least one. If you need more than five or six, the story is probably too big. Split it.

Who writes Salesforce user stories?

Usually the business analyst or product owner, but they should be shaped in a workshop with the people who will build, test and use the feature.

Should acceptance criteria name Salesforce features?

Avoid it. Say what the user can do, not which button or automation does it, so the team can pick the best solution.

Where should you go next?

• The Salesforce Business Analyst study guide covers all six exam sections.
• Business Analyst practice questions with explanations.
• Business Analyst vs Administrator if you're deciding which cert to take first.

Hope this helps!

Best,

Nick