The Short Answer
A well-crafted Salesforce story describes who, what they're trying to achieve, and what will be true after the action — not which field appears on which screen. The simple test: If acceptance criteria can be written without knowing whether the implementation will be Flow, Validation Rule, or Apex, the story is correctly formulated.
The common pitfall is a story that already contains the solution. The moment it reads "Add a Picklist field to the Opportunity screen," the discussion about the process is over before it began.
A Structure That Works
| Component | Role | Quality Test |
|---|---|---|
| Context | Who is the user and when are they here | Real role, not "user" |
| Intent | What they are trying to achieve | Formulated in business language |
| Acceptance Criteria | What is being tested | Can be run as a scenario with test data |
| Edge Cases | What intentionally fails | At least one negative |
| Out of Scope | What is explicitly excluded | Prevents arguments during acceptance |
The last point saves most disputes. An explicit statement that what is not included is indeed not included is worth more than three paragraphs of description.
Breakdown: Vertical Slice, Not Layers
The temptation in a CRM project is to break it down by technical components – data model first, then automations, finally reports. The result is that there's nothing to demonstrate until the end, and no one knows if the process works.
The correct breakdown is vertical: one complete, end-to-end scenario for one user profile. A single opportunity that is opened, progressed, closed, and appears in a report is worth more than ten defined objects without a process. Later, profiles and scenarios are added around that same skeleton.
Prioritizing When Everything is Urgent
Three criteria are sufficient, in this order:
- Blocks Go-Live? – Without it, the process is incomplete. There's no room for negotiation.
- How many users per day? – Frequency trumps intensity of complaint. An item affecting 80 daily agents precedes a request from one manager.
- What is the cost of deferment? – Does the cost of implementation increase if we do it after launch? A data model change yes, a report change no.
Anything that doesn't pass these three goes into the Parking Lot. This separation prevents the backlog from becoming an archive of wishes. In-depth information on managing scope changes can be found in Scope Creep and Change Control.
Requirements Debt: The Silent Failure
Requirements debt arises when a story is closed without deciding what happens in an edge case – it's left as "we'll deal with it later." After launch, these edge cases become the majority of support calls.
The simple discipline: an item is not closed without a documented decision for every open question recorded in it, even if the decision is "intentionally not addressed." Documenting the waiver is better than a lack of documentation.
Connection to Testing
Well-written acceptance criteria are essentially the UAT scripts. When written after development, UAT becomes a demonstration of what was built instead of a test of what was required. The sequence is detailed in the UAT Guide.
Summary
A quality backlog is not long but clear: each item states who it's for, what will be measured as success, and what is explicitly not included. These three questions, asked before building rather than after, determine almost all post-project acceptance quality.