It’s these “business representative on your side” benefits when asking for something, coupled with the “straight from the horse’s mouth” clarity of business direction that convince many people that a BA cannot as successfully play the role of a PO. In theory, I think this is true, but life is complicated and messy. Is a good BA better than a poor PO at this work? What about BA’s helping fill the gap of an absent PO? Is a PO supported by a BA the best of both worlds? Let’s look further.

The Business Analyst (BA)

As we explored in the previous article, BAs typically have very strong requirements elicitation skills coupled with experience articulating these requirements. These are supported by benefits verification skills and the communication ability to successfully bridge the business to technical team gaps. They are also typically trained in technical analysis and design and so can help with tasks such as splitting large stories into smaller ones, modeling workflows, modeling data, clarifying business rules, and making sure non-functional requirements are also addressed.

The training and skills of a typical BA qualify them well for undertaking most of the backlog management functions of a PO. They typically bring deeper technical skills, but shallower business knowledge. They are often more project and tactical focused while the PO is more business strategy and customer focused. Some of these overlapping views, roles and skills are shown in the Venn diagram below:

The “Usually…” and “Can be…” qualifiers are important. There are some very technical Product Owners and some very business savvy BAs. If you work long enough with a team or business unit it is normal and desirable for knowledge and skills to be transferred. Also, people change jobs from business-to-technical and technical-to-business roles. People are diverse and complicated, roles help us talk about work, but rarely capture what really goes on or what it is a project team ideally needs.

Then there is the personality and soft-skills view to add into the mix. I would rather take a collaborative BA or PO who you can get on with and iterate to a great solution even if they are lacking in some business knowledge or technical appreciation, over a non-cooperative genius that nobody wants to work with. When communication and collaboration stop, or are severely compromised, role definitions and skills don’t even make it to the playing field to take part.

Common BA/PO Patterns

Let’s review some scenarios that often play out on project teams. We will start with the classic PO as bridge or link from the business community to the Development team. This is shown below in the first diagram labeled “1) PO as Bridge”.

In “1) PO as Bridge” the PO plays the traditional role as dedicated and direct connector between the business community and the development team. This role when performed properly delivers the benefits of effective backlog management and the beyond backlog management benefits also.

A situation we want to avoid is BA acting as a Go-Between from the business to the development team, as shown in “2) BA as PO Go-Between”.

Here the direct connection from the business community to the development team is funneled through a BA. Presumably for good intentions, because the BA can translate business to technical and vice versa, or they are skilled in requirements management and associated software tools. However, the reason the agile manifesto includes the principle “Business people and developers must work together daily throughout the project” is because of the rich flow of requirement and business priority nuisances that occur through daily interaction. Inserting a BA acts as a filter reducing the flow of information to the development team and diluting the message through translation and the relaying of it.

Having a BA as Proxy PO is a common compromise situation.

Often a PO is not available or only available sporadically and so a BA is assigned the role as PO. The problem here is while a BA may be great at backlog management, they cannot bring the full complement of “Beyond the Backlog Benefits” we talked about earlier. These include:

• Inside introducer to other business stakeholders
• Gateway to additional funding
• Business advocate for project issues

There might also be authority challenges within the team. Development team members rarely question or ignore business priorities coming from a PO sourced from the business, but this can happen with a BA playing the PO role, leading to friction on teams.

A better solution is “BA as PO Supporter”

Here the BA supports the PO, but does not act as a Go-Between. The BA can help with activities like story splitting and making sure common non-functional requirements are addressed. They can also help ensure business rules are enforced and interface requirements are met. BAs can temporarily stand-in to answer questions from the development team when the PO is not available, but always with the understanding the PO has ultimate authority.

Good BAs can also help POs accelerate their learning of backlog management activities and tools by providing coaching. However, while the BA and PO roles overlap, they are not synonymous or interchangeable. In terms of preferences, in the ideal world I would like to have both skilled and personable POs and BAs available to project teams. Failing that, an engaged PO or part-time PO backed up with a BA in a supporting role.

Beyond this point moving from the ideal, we encounter issues. Absent, or belligerent POs could be replaced by a BA or worked through with the development team. That’s the wonderful truth about people and projects, outside of some basic ideas it becomes very difficult to determine what is best and the consequences of making changes. The good news is that agile environments provide quick cycles to evaluate experiments and changes.

Hopefully these ideas and diagrams provide some tools to have conversations with stakeholders and determine your best use of people given your unique organizational and project characteristics. From there you can try the roles, then inspect and adapt the approaches used based on the results obtained.

[I first wrote this article for Project Managment.com and it was published here.]