I have heard in some work places most of PRD and BRD are written by BA. So just wanted to know how the things actually work between BA and PMs.
I am currently still a student. Trying to learn how everything works.
9 Likes
As a casual lurker in a field which isn’t mine, I usually can piece together these acronyms y’all use, however the acronyms in this post are going over my head. Mind helping me out?
8 Likes
PRD: Product Requirements Document
BRD: Business Requirements Document
BA: Business Analyst
UX: User Experience
Hope this helps
9 Likes
More knowledge for you:
AC (Acceptance Criteria) is often written by a BA (Business Analyst) or Product Owner (and by extension, sometimes PdMs). The point of it is to simply and clearly state everything that should be completed & functioning by the time the User Story/Work Item is done. Ideally, it is written in a way that a business stakeholder (or the PO) can go into the system and check for him/herself.
People struggle with differentiating between AC and AT (Acceptance Tests, aka testing scenarios).
Testing scenarios should be very in-depth and extensive. They are often written by a QA individual, although sometimes the developers themselves will write them, and other times, more technically-inclined BAs will write them.
9 Likes
Thank you! You guys rock. I am also learning and trying to pivot into that space . Got a lot to learn with the abbreviations.
Would you say that whoever writes PRD/ACs are company by company? Lately I am getting the impression its within PM wheelhouse to come up with ACs for next upcoming sprints.
9 Likes
Yes, company by company, even team by team within the same company. It’s fair to say that ACs may be written by anyone in the scrum team. That includes BAs, POs, PMs, or even developers and testers.
What level of AC are you talking about? ACs for Epics/major projects? Or for user stories?
9 Likes
Product Managers and Project Managers are different? How? Wouldn’t your project be the product?
10 Likes
They are completely different, unique, and separate roles.
The caveat is that many PdMs will often have some PjM-type tasks in their day-to-day.
PjMs will very rarely do things that a PdM does. PjMs typically/traditionally have little tech skill/knowledge and are often not involved in much of the actual project work (discussion about code/bugs, strategic/business discussions, etc.) They typically focus on scheduling meetings, being present in meetings (good ones will actually take meeting notes… that’s rare), sending out communications about project status, creating project status deliverables (charts and such), etc. Additionally, the idea of a Project Manager is sort of blending/morphing into “Scrum Master” as most orgs are undergoing an Agile transformation. That’s a whole other conversation.
Product Management is a different skillset, but often, PdMs are stuck doing some of the above tasks due to org size/structure.
10 Likes
I think we are going on a different track altogether. Expanding the acronyms was okay. I suggest we start a different thread for basic education in this field.
My question was regarding the work culture and relation between a BA and the PM. I would really appreciate if someone could focus more on this.
10 Likes
Aren’t BA with these responsibilities Product Owner/PM in most companies?
9 Likes
I would use BAs to make sure the stories in the backlog were good to go prior to sprint planning. They were the conduit between product and engineering on the nitty gritty stuff, the details, the solution research. I also used them as the source of truth for what happened in meetings since I wasn’t always able to attend everything and I am also not the best note taker when I do attend (in my experience engineering just never likes to take notes).
8 Likes
Also some places don’t have BAs. Something to consider that not every place has the same model So don’t worry too much about it
7 Likes
In my experience, the BAs are part of the dev team and determination of the “how” or the solution belongs on that team. The PMs set a direction, identify the outcome(s) desired, understand the business case and objectives, indicate the priority of what to work on, and verify the solution meets the goal.
So when a certain idea/feature/initiative reaches the top is the so called pile/backlog and is prioritized to be worked on, I’ve handed off to the BA to work with dev to identify and document the “how” of the solution, gets answers on questions, and supports the dev team in that regard. That is just how I’ve always worked with BAs, I’m sure it’s different at different companies.
6 Likes
Isn’t that System Analyst rather than Business Analyst?
5 Likes
Yes it is. BA work in the problem domain while SA work in the solution domain. BA helps to understand the real needs and requirements on business level, but they don’t even use the word X or Y system. This is the territory or the SA who has an overview of the currently running system and technical details. It might happen that someone is called a BA is actually an SA or someone having both hats, without even knowing.
4 Likes
Like anywhere role titles can be flexible, my org calls that role “tech BA” rather than systems analyst.
I feel like “problem domain BA” probably just isn’t a necessary role in a product org where each team has a PM, designer, and tech lead.
3 Likes
Just keep in mind, everything works differently at different companies. In some the companies, the PM can also be the product marketing manager, the business analyst, and/or a program manager all in one. Unfortunately, some companies treat product managers as data entry specialists and little more.
2 Likes
The way I think of it is the buck stops here. It is my responsibility to do the BRD. If a BA can’t do them, then I have to. If I can’t do them, then I have to coach someone to help me.
1 Like
I have no idea, if that gives you any hope.
Was a PM for a small startup, am now a senior tech BA for a large enterprise. I do all the same things I did previously, flexing between designer, business mindset and getting into some of the technical aspects. I meet with the VP and directors to demo, write user stories and ACs, gather and research, create artifacts and decks to align teams…
It really is just title swaps for the industry and business itself.