How to Write Salesforce User Stories and Acceptance Criteria with AI

A language model will write you a clean user story in four seconds. A study published in March 2026 found that story will be more atomic, more minimal, more readable and less ambiguous than one written by an experienced agile practitioner.

The same evidence says it will be worse on exactly two things, and those two things are the ones that matter most when the story reaches a Salesforce org.

This page covers what a Salesforce user story has to contain, what acceptance criteria have to prove, where generated stories reliably break, and how to use agents on the part of the work they are good at. The worked examples are Salesforce examples, because the difference between a generic story and a Salesforce story is the whole subject.

A user story describes intent while acceptance criteria bind the configuration

Two artifacts do two jobs, and conflating them causes most of the rework.

The story states who needs something and why. Salesforce teaches the canonical form: as a [role], I want [action], so that [outcome]. The story is deliberately short. It is an invitation to a conversation rather than a specification.

Acceptance criteria do the specifying. Salesforce defines them as a set of statements, each with a clear pass or fail result, that specify the conditions under which a story is fulfilled. Every story should carry at least one. Each criterion should be independently testable and answerable with true or false.

One rule from that guidance is worth holding onto, because AI-generated criteria violate it constantly. Acceptance criteria should state intent, not solution. Salesforce gives its own pair of examples. Writing that a district manager can click an Approve or Disapprove button is a bad criterion, because it prescribes the interface. Writing that a district manager can approve or disapprove a discounted product price is a good one, because it states the outcome and leaves the implementation open.

Hold that rule in mind. Later on this page it collides with something specific to Salesforce, and the collision is where teams get hurt.

Two types of acceptance criteria are in common use and both satisfy the pass-or-fail test. The checklist format states each condition as a flat assertion. The Given-When-Then format, borrowed from behavior-driven development, states a precondition, a trigger and an expected result: given an opportunity with a discount above twenty percent, when the sales manager submits it, then an approval request routes to the regional director. Gherkin phrasing suits anything with a trigger and a state change, which covers most Salesforce automation. The checklist suits visibility and access conditions, which have no trigger. Most Salesforce stories need both.

One older framing still worth knowing, because it explains why the story is short. The three Cs, proposed by Ron Jeffries in 2001, describe a story as a Card, a Conversation and a Confirmation: the written statement, the discussion it triggers, and the acceptance criteria that settle it. Salesforce’s guidance carries the same logic when it calls a story an invitation to a conversation. The criteria are the confirmation half, which is why a story without them is only a third of the artifact.

Two neighboring artifacts are worth separating from acceptance criteria, because teams routinely collapse them. An epic groups related stories under one business outcome and carries no acceptance criteria of its own. A definition of done applies to every story in the backlog, covering things like peer review, deployment and documentation, and does not change story by story. Acceptance criteria sit between them and are specific to one story.

Salesforce teaches INVEST, and generated stories fail one letter consistently

The quality standard Salesforce trains analysts on is INVEST, a checklist created by Bill Wake in 2003. A story should be Independent, Negotiable, Valuable, Estimable, Small and Testable.

Now put that next to the research. A paper in the REFSQ 2026 workshop proceedings, from the conference held in Poznań in March 2026, generated 9,000 user stories by running 1,000 source inputs through three models under zero-shot, one-shot and two-shot prompting. Every story was scored against the Quality User Story framework, a thirteen-criterion standard published by Lucassen and colleagues in 2016, and compared against a baseline written by two agile practitioners.

Treat this as workshop-track work rather than a settled result. The paper reports its human baseline as 183 stories in the methodology and as 200 in the results, which is the kind of discrepancy that belongs in the open before anyone quotes the table.

The pattern in the published results is sharp.

Seven criteria favor the machine. Two favor the human, and one of those two is the I in INVEST.

The researchers describe the failure mode plainly: models produce semantically overlapping output from similar inputs. Feed a model twenty discovery notes about case management and it returns twenty stories that read beautifully and describe roughly six distinct things. A separate human evaluation in the same study scored the best model slightly above the expert baseline on readability, understandability and specifiability, which is the trap. The output looks better while the backlog underneath it gets worse.

Two honest caveats belong with those numbers. The source material was app store reviews for health and fitness applications, not Salesforce discovery sessions, so the domain is not ours. And the absolute values are low across the board, including for humans, whose independence score of 0.32 is nothing to celebrate. Read the table as a relative signal about where generation helps and where it does not, not as a grade.

The practical instruction follows directly. Generation is a drafting gain and a deduplication risk. The review step that matters is not “is this story well written” but “is this story the same as one of the other nineteen.”

Prompt structure moves story quality more than model choice does

One finding in that study is immediately usable and cuts against how most teams prompt.

Few-shot prompting beat zero-shot prompting consistently, and the difference was statistically significant at p below 0.0001. Two examples beat one example. The gap between models, meanwhile, was tiny, generally under 0.003 on the overall quality score.

Structural adherence showed the same effect more starkly. One model deviated from the canonical story template roughly half the time when given no examples, and reached near-perfect adherence when given two.

So the lever is not which model you license. The lever is whether your prompt carries two real examples of a well-formed story from your own project, with your object names and your role names in them. Teams that paste a bare instruction get the worst version of a capable model.

Salesforce acceptance criteria name access, and generic criteria omit it

Here is where Salesforce guidance and Salesforce reality pull against each other.

The intent-not-solution rule is correct for the story and for most criteria. But Salesforce is a configuration platform where the same functional outcome can be built five ways, and where the defects that reach production are rarely functional. They are access defects, data model defects and automation-collision defects. A criterion that stays purely at the level of business intent does not catch any of them.

A model trained on general agile writing produces criteria at exactly that level, because that is what the literature it learned from contains.

Consider a real request: sales managers need to see the discount field on opportunities so they can approve exceptions.

A generated criterion set typically looks like this.

• A sales manager can view the discount on an opportunity.
• A sales manager can approve or reject the discount.
• The approval outcome is recorded.

Every line passes the Trailhead test. Each is a statement with a pass or fail result, each states intent and not interface, and each is independently testable. The set is also insufficient to build from, because it is silent on every question a Salesforce build actually has to answer.

None of those are implementation trivia dressed up as requirements. Each one changes what gets built, and each one is a defect if it is decided silently by whoever picks up the story.

The workable rule is a split. Keep the story and the functional criteria at the level of intent, exactly as Salesforce teaches. Then add a second criteria block that states the access and data conditions the story assumes, because on this platform those conditions are part of the outcome and not part of the design. A manager who can technically approve a discount but cannot see the field has not received the thing the story promised.

A field carries dependencies that a transcript never mentions

The deepest limitation of generated stories has nothing to do with writing quality.

A model drafting from a discovery transcript knows what people said in the room. It does not know what is already in the org. That gap produces stories that are well-formed, well-scoped, and wrong about effort by an order of magnitude.

The founder of Elements.cloud, writing on Salesforce Ben about a backlog of over a thousand stories, recorded the canonical version of this. A colleague asked him to add one value to the Opportunity Stage picklist. He wrote the story without running impact analysis, because it was obviously trivial. The Stage field turned out to carry twenty-one Flow dependencies, seven Process Builders and seventy-one reports, and the change cost two hours of cleanup. The source is a vendor that sells dependency analysis tooling, and the anecdote predates Process Builder’s retirement, so treat the specific counts as illustration, not benchmark. The mechanism is what generalizes.

No amount of prompt engineering closes that gap, because the missing information was never in the prompt. Closing it requires the story to be drafted against org metadata as well as against the conversation. A story that says “add a picklist value to Stage” is a different story once it carries the line “this field has twenty-one automation dependencies and appears in seventy-one reports,” and it is a different story in the only way that matters, which is what the team agrees to before committing.

This is also the argument for writing the story and the impact note together instead of sequentially. Analysis done after the story is written gets skipped under deadline pressure. Analysis that produces the story cannot be.

Agent features need guardrails where deterministic features need steps

A newer problem is arriving in Salesforce backlogs, and the classic story form handles it badly.

A Senior Consultant at Deloitte Digital argued in January 2026 that requirements for Agentforce work are shifting from describing paths to describing behavior. Her contrast is clean. The old form specifies that checking a Refund box sends email template five. The new form specifies that the system acts as a returns coordinator, offers a discount when a customer expresses frustration, and states standard procedure when the tone is neutral.

The second is not a worse-written story. It is a different artifact, because the system it describes interprets a situation rather than following a branch.

What that artifact needs, and what a classic story lacks, is a set of boundaries. Her examples are the right shape: the system should never promise twenty-four-hour delivery for oversized products; the case should not escalate if the customer already received compensation within the last thirty days. Those are guardrails, and they are acceptance criteria for a behavior rather than for a transaction.

Three fields belong in a story for an agent feature that do not belong in a story for a Flow. The role the agent occupies. The decisions it may make without a human. The conditions under which it must stop and hand off. Teams that skip these do not get a broken agent on day one, they get an agent nobody can evaluate, which surfaces later as an inability to say whether it is working. The same discipline underpins deciding who owns agents after go-live and testing agents before they reach production.

The author’s own conclusion is the balanced one, and worth keeping: behavioral specification sits alongside the user story and does not replace it. Deterministic features still deserve the classic form.

Six checks separate a drafted story from a buildable one

Generation changes where the analyst spends time. These are the checks that survive the change, in the order they are worth running.

Check independence against the rest of the batch, not against the template. This is the criterion the research says models lose on. Read the new stories as a set and merge the ones describing the same underlying change.

Confirm the role is a defined persona. Salesforce lists an undefined who as a documented story mistake. A generated story will happily address “a user,” which tells the builder nothing about profile, permission set or license type. Salesforce recommends holding a story-writing workshop near the start of a project, with admins, developers, designers and actual users present, precisely so personas exist before stories reference them.

Check the why is a business outcome, not a restatement. Circular stories of the form “I want X so that I can do X” are the classic tell. A model produces them readily because the input transcript often contains them.

Add the access criteria. Profiles, permission sets, field-level security, record visibility. This is the block generic generation never produces.

Run impact analysis on every named field and object. Before the story is estimated, not after.

Confirm every criterion is answerable true or false in a sandbox. If a tester cannot reproduce the condition with real data and get a definite result, the criterion is a wish. Criteria describing a validation rule need the rejected values written down, not implied. Salesforce names vague acceptance criteria as one of its five documented story mistakes, and the reason it gives is exactly this: without testable criteria there is no reliable way to measure completion.

Note what is absent from that list. None of these six checks is “rewrite the prose.” Generated stories are already better written than hand-written ones on most measures. Spending review time on wording is spending it in the one place the machine already wins.

Where the stories then live is a separate decision and matters less than it seems. Most Salesforce teams keep them in Jira, some in Azure DevOps, some in Salesforce’s own Agile Accelerator, and some in the work items of a release pipeline. What travels badly between those tools is the analysis behind the story, so whichever you use, keep the impact notes attached to the story rather than in a document nobody opens again.

GetGenerative.ai drafts stories from discovery and grounds them in org metadata

The two failure modes on this page are duplication and org-blindness, and they call for different fixes.

Three of the seven GetGenerative.ai agents sit on this specific problem, and they map onto the sequence the work actually follows.

Discovery handles the input layer, converting workshop conversations into structured insights, follow-up questions and process maps. Working from a structured artifact instead of a raw transcript is what makes the duplication problem tractable, because overlapping requests become visible before anything is drafted as a story.

Design takes that structure and produces the stories and the low-level solution together. Drafting both at once matters more than it sounds: the solution view is where an analyst notices that four separately worded requests resolve to one field change.

Metadata addresses the org-blindness failure. It reads the existing org and explains it in plain English, so a draft can carry what a named field already touches instead of assuming the field is new. That is the difference between a backlog that estimates accurately and one that finds its dependencies halfway through a sprint.

Producing stories as reviewable artifacts rather than as chat output matters for the review step too. An analyst can approve a story, and approval is the control that the independence problem needs. Downstream, those approved stories become the input to the solution design document and the rows of a requirements traceability matrix, and they are what UAT scripts eventually test against.

Teams weighing this up can review plan options for analyst teams before committing to a workflow change.

What changes for the analyst, and what does not

The research supports a narrower claim than either side of the usual argument.

Generated stories are not worse than hand-written stories. On seven of nine measured quality criteria they are better, and on human-judged readability and understandability they edge ahead of practitioners. Anyone claiming AI writes poor user stories is arguing against measured evidence.

Generated stories are also not sufficient. They repeat each other, they do not know the org, and they produce access-blind acceptance criteria because general agile writing is access-blind. Those are not prompt problems. Two of the three are information problems and one is a structural property of how models generate from similar inputs.

So the analyst’s job moves rather than shrinks. Less time producing prose, more time on deduplication, persona definition, access conditions and impact analysis. That redistribution is the same one showing up across the business analyst role and across Salesforce delivery as a whole, where generation gets cheap and verification does not.

Start with the prompt. Put two real stories from your own project in it, with your object names, and you will fix the largest single quality variable the research identified before you change anything else.

Questions analysts ask about writing Salesforce user stories with AI

What is the correct format for a Salesforce user story?

Salesforce teaches the canonical agile form: as a [role], I want [action], so that [outcome]. The role should be a defined persona and not a generic user, and the outcome should be a business benefit and not a restatement of the action. Acceptance criteria are added separately and carry the testable detail.

How many acceptance criteria should a user story have?

Salesforce states that every user story should have at least one, and that each criterion must be independently testable and answerable with true or false. There is no upper limit, but a story needing a very long criteria list is usually too large and should be split.

Can AI write acceptance criteria for Salesforce?

It can draft them, and research from 2026 shows generated stories score well on clarity and structure. Generated criteria tend to stay at the level of business intent and omit the access conditions that Salesforce builds depend on, so profiles, permission sets, field-level security and record visibility usually need to be added by an analyst.

What is the INVEST checklist?

INVEST is a quality checklist created by Bill Wake in 2003 and taught by Salesforce for assessing user stories. A story should be Independent, Negotiable, Valuable, Estimable, Small and Testable. Independence is the criterion generated stories fail most often, because models produce overlapping output from similar inputs.

Do user stories still work for Agentforce agents?

They work for deterministic features and fall short for agent behavior. An agent interprets situations instead of following a fixed path, so its specification also needs the role it occupies, the decisions it may take unaided, and the conditions under which it must hand off to a human. Practitioners describe this as a behavioral specification that sits alongside the story and does not replace it.

Should AI-generated stories be reviewed differently from hand-written ones?

Yes, though not in the way teams expect. Generated stories are usually better written, so reviewing prose wastes the review. The checks that pay are deduplication across the batch, persona definition, access criteria and impact analysis against existing org metadata