PO vs BA vs PM in a Bugs Scrum
Hello,
Looking to get some input on the following practices. Joined a new team that works specifically on bugs that come up.
As the PO - I help prioritized the backlog, in addition to managing the business requirements. However, in this organization, the BA plays a heavier role in getting the full technical/business requirements in the tickets, and running the backlog grooming session.
However, this is very odd to me. In my previous org. I am used to running standups, and backlog grooming (including responsibility for ensuring that the tickets had all the information).
Sometimes I chime in during backlog grooming, to clarify questions/requirements -- but most of the discussions happen between the engineering leads and the BA to confirm the requirements.
Would like to hear everyones thoughts. I want to make sure I'm involved but also know that the BA/PM have a role too and don't want to step on their toes.
Thanks
PQ
the BA plays a heavier role in getting the full technical/business requirements in the tickets, and running the backlog grooming session.
Regardless of who does what, who ought to be held accountable for maximizing product value? You, or the BA?
However, this is very odd to me. In my previous org. I am used to running standups, and backlog grooming
Why would you run anything at all? In Scrum we want people to self-manage and to run things for themselves. Bear in mind that as a Product Owner, for example, you have no need to attend a Daily Scrum at all.
Scrum doesn't recognize the BA or PM roles. The Scrum framework only provides three roles - Scrum Master, Product Owner, and Developer. Each role has specific responsibilities and accountabilities.
A few things do stand out to me, in the description of your way of working:
- The idea that there are "full technical/business requirements" in tickets during a refinement session raises a few questions. That almost seems like a waterfall process to me. Depending on the organization's tolerances for risk, you may see more or less requirements definition as part of refinement, but one would almost always expect some emergent requirements during the course of the Sprint.
- The Product Owner should never run standups. Standups are primarily for the Developers, although I do find it very useful for the Product Owner to be in attendance. I encourage the Developers to run the event themselves, with some coaching from the Scrum Master on effective techniques when requested.
- There are many ways to run refinement. There's not even a requirement for a meeting, although I do find it helpful to get everyone together and aligned.
I do find that Scrum is a bit lacking in how product management is defined. A singular Product Owner can rarely perform all of the functions associated with product management. To this end, the Scrum Guide does refer to the fact that a Product Owner "may represent the needs of many stakeholders", but that the Product Owner is "not a committee". There could be many analysts, user experience researchers and designers, sales people, marketing specialists, and more that are represented in the decisions of the Product Owner. Business analysts could support a Product Owner, but a true Product Owner will have the final decision to resolve issues that impact the Product Backlog and maximizing the value delivered by the Scrum Team.
Thanks for your feedback. I find that sometimes that in this structure, the BA and I are very similar. Except the difference is the BA looks to me to tell her which to prioritize and scope out.
and during a grooming session, the BA and lead engineer are having the discussions, and everyone else is pretty much quiet.
I guess every company runs things differently.
Every company that I have come across treat Product Owners as upgraded Business Analysts. That is, the Product Owner is the CEO of the Product Backlog and not the Product. They report to a Product Manager and either that person or somebody in leadership makes the decisions.