What Developers Actually Want From Business Analysts (Lessons From a 9-Year Salesforce Dev)
Ever wonder what your developer is really thinking when they open your ticket? In this fireside chat, I sit down with Diana — a Salesforce developer with 9 years of experience across Accenture, IBM, iHeart, and Sentinel One — to get the honest developer perspective on what makes a business analyst exceptional to work with.
Ever wonder what your developer is really thinking when they open your ticket? I did too, so I asked one. For my fireside chat series, I sat down with Diana, a Salesforce developer I used to work with at a large consulting firm. She has nine years in the ecosystem across Accenture, IBM, iHeart, and now SentinelOne, and she was refreshingly honest about what makes a BA easy (and hard) to build for.
Watch the full conversation on YouTube
Developers read your story literally
The biggest thing Diana wishes every BA understood is that developers follow your story to the letter. If a detail isn't there, the developer has to fill the gap with an assumption, and if that assumption is wrong, the work gets sent back and redone. Nobody wants that cycle, least of all a team trying to close five tickets in a two-week sprint.
That's why "create a field" is never a complete requirement. Diana walked through all the questions hiding behind that one line: who needs access to it, who gets read versus edit, where it goes on the page layout, what the label and API name should be, and whether it needs help text (and if so, what that text actually says).
What a gold-star ticket includes
When we talked about what makes a ticket "ready to go," Diana's answer was simple: as long as all the details are there, she's happy. Here's the checklist I pulled from our conversation that you can use before you hand anything off.
☐ The goal: what the business is trying to accomplish and why
☐ The exact ask, including labels, API names, and help text where they apply
☐ Placement, such as "put it in this section, underneath this existing field"
☐ Who should and shouldn't see or edit it
☐ Edge cases and dependencies, the "trickle-down effect" of a small-looking change
☐ Clear acceptance criteria
☐ Testing scenarios, so the developer can check their own work before passing it back
That last one might surprise you. Diana likes having testing scenarios because it lets her confirm she's covered everything before she says "this is ready," which cuts out a whole round of back-and-forth.
Share the goal, not the solution
As BAs, we're trained not to put tech specs in a story, and that's where a lot of junior analysts get stuck. Where's the line between giving enough detail and solutioning? Diana's answer kept coming back to one thing: the goal. If you only say "we want to implement this," the developer can't help you. If they understand where the business is trying to go, they can bring you the best way to build it. You bring the business request, they tell you how it gets built, and then you agree on it together.
The communication mistake that causes the most problems
According to Diana, trouble starts when a BA doesn't fully understand the ask themselves. A request can look small and still have dependencies or edge cases tied to it, so before you write the story, make sure you understand both the ask and its ramifications. This is also why refinement sessions matter so much. Finding out a week into the sprint that nobody fully understood a story is a much harder conversation than catching it up front.
How to handle a ticket that's missing something
It happens to everyone: a developer comes back and says the ticket doesn't have what they need. Diana's advice was to just be honest. Go to your developer and say something like, "I have this story and I'm not sure where to start. Can we brainstorm what you need?" Developers respect that far more than guessing.
One thing I'd add from my own experience: have coffee chats with your developers before there's a problem. Getting to know how someone works makes those tougher conversations a lot easier when they come up.
Every role has its own superpower
My favorite part of the conversation was near the end, when Diana described the best team she'd been on. Everyone had their own strengths, and nobody ever felt dumb for asking a question because the answer was always "I've got your back." That's the relationship a strong BA and developer can have when the tickets are clear and the communication is open.
If you want to hear all of Diana's advice, including the stories behind these tips, watch the full fireside chat on my YouTube channel. And if you're building your BA skills, I cover user stories and acceptance criteria in depth in my Business Analyst Mastery course.
Keep watching: Day in the Life of a Business Analyst | WFH Diaries
A special thank you to Diana, for being a special guest in our series. See you in the next one!
