Should the client's business analyst write user stories for your Salesforce project?

Here's a position I hold pretty firmly: user stories on a Salesforce implementation project should always be written by the vendor, not the client's internal BA. Not because client BAs aren't capable, but because of what tends to go wrong when they hold the pen.

That's my position. Now I'll share the rationale behind it.

The blank canvas problem

Every generalist BA is trained to write system-agnostic user stories and acceptance criteria. From a purist BA standpoint, that's correct practice. You describe the need, not the implementation, so the solution isn't constrained before anyone's had a chance to design it properly. Before I worked with Salesforce that's exactly how I was taught to write user stories.

That approach works when the underlying system is a blank canvas: an in-house CMS, a bespoke Java application, a purpose-built app built from scratch. It falls apart the moment the underlying system is a platform such as Salesforce, or any other commercial-off-the-shelf system for that matter.

Salesforce and its myriad of products (Sales Cloud, Nonprofit Cloud, NPSP, Marketing Cloud etc) is flexible enough that most requirements can be met several different ways. But it also comes with a large body of native functionality that already solves problems people don't realise are already solved. When a generalist BA writes acceptance criteria without knowing what's already sitting in the platform they end up describing a system that doesn't exist yet, and doesn't need to.

The result is acceptance criteria that quietly demand a custom rebuild of something Salesforce already does out of the box. Nobody intends this. It happens because the BA is writing to a methodology rather than a platform.

The cost of undoing it

Once those stories are written down and shared with the client's stakeholders, they stop being a draft. They become the frame of reference everyone in the room uses to judge progress, whether or not it was ever technically accurate.

At that point, the consultant's job isn't just to write the correct version. It's to have the conversation where you tell the client's BA "that's not how Salesforce works", explain why the UACs as written would mean custom-building an entire suite of things the platform already provides, and then spend time and goodwill unwinding a document that's already taken root in people's heads. That's effort spent managing a misunderstanding you didn't create and had no say in preventing.

Whose risk is it?

There's a second problem, and it applies even if the client's BA happens to be genuinely Salesforce-fluent. If the vendor is expected to build against user stories they didn't author, the vendor has effectively lost control of the thing they're accountable for delivering. The bigger the scope covered by client-written stories, the bigger that exposure becomes.

Imagine commissioning a builder for a new house, then insisting they use a cement mix you sourced from a recipe on the internet. If the foundation cracks, is the builder still on the hook for it? Somebody made the call on the materials, and it wasn't the person holding the liability. User stories are the materials list for a Salesforce build. If the client wrote the list, the vendor shouldn't have to explain the cracks.

And thirdly, most Salesforce consultancies have their own custom-built solutions to address common use cases (they might call them accelerators or similar). The client BA would of course not know about them and therefore naturally wouldn’t have them in mind when drafting user stories.

Where client BAs still matter

If you're a client BA, please don't worry though, there's still plenty for you to do. Client BAs are often the best people in the room to deliver process diagrams, for clarifying business rules, and for capturing how the organisation actually operates day to day. That knowledge is valuable and a Salesforce consultant would be foolish to ignore it.

They're also essential at the other end of the process: reviewing and signing off on the stories the vendor produces. That sign-off isn't a formality. A vendor should never be building against user stories the client hasn't reviewed and approved, regardless of who drafted them. The distinction that matters isn't whether the client's BA is involved, it's who holds the pen during drafting and who holds the approval before build starts.

The one exception

There's one stage where client-drafted stories can be genuinely useful: presales. Before any commitment has been made on the vendor's side, seeing a client's own attempt at user stories can tell you a lot about their priorities and give you an early read on their internal terminology.

At Giveclarity we've had a handful of presales engagements where a client's BA wanted to draft, or help draft, the project's user stories. It's an understandable instinct. It looks like a natural place to put the responsibility, and it saves them budget.

We tried it once. We don't do it anymore. Once a project moves past presales into Discovery and Build, client-authored stories stop being a useful data point and start being a risk sitting inside the delivery.

Where this leaves you

In my experience, the BA relationship on a platform project only works one way round:

• The vendor writes the stories, because the vendor is the one who understands what the platform already does and what it will cost to fight it.
• The BA reviews and signs off on every one of them, because that's what keeps the vendor accountable for what gets built.

Client BAs still have real work to do on process, rules and terminology, and their sign-off is not optional. But the pen stays with the people who carry the risk of what happens if the story is wrong.