The Business Analyst and the Product Owner

This content is syndicated from LeadingAnswers: Leadership and Agile Project Management Blog by Mike Griffiths. To view the original post in full, click here.

BA and PO rolesIn my last article we talked about the role of the BA on agile projects, reviewing what stays the same and what changes from traditional approaches. In this article, we will review the contentious topic of how the role of the BA varies and overlaps with the Product Owner (PO). We cover the similarities and differences including danger signs such as “BA as PO Go-Between” and positive patterns such as “BA as PO Supporter”.


The Product Owner (PO)

First, let’s make sure we understand the role of the Product Owner (PO). It originated in Scrum but is often also used beyond Scrum in other agile approaches and hybrid approaches. The Scrum definition of the role is the person responsible for maximizing the value of the product and the work of the development team. This includes being responsible for managing the Product Backlog. Extreme Programming (XP) has a similar “Customer” role, DSDM has one or more “Business Ambassadors” depending on the scale of the project. They all play a similar role in stewardship of the backlog, including:


  • Ensuring that the product backlog is visible, transparent, and clear to all, showing what the team will work on next
  • Ensuring the team understands items in the product backlog to the level needed
  • Clearly expressing the product backlog items
  • Ordering the items in the product backlog to best achieve goals and outcomes
  • Optimizing the value of the work the team performs


Benefits Beyond Backlog Management

In addition to this backlog focused work, the Product Owner is often the primary interface to other business stakeholders. They help teams gain access to business subject matter experts for insights on topics where the Product Owner may not have all the answers. They also often act as a gateway to funding, making the business case for additional funding requests, or as a powerful ally when asking for roadblocks to be removed. Playing the “Business is asking for X” card is typically stronger than the “Team is asking for X” card when asking for an exemption from process, or to expedite an issue.


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:

Common BA and PO roles

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”.

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”.

2 BA as 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.

3 BA as proxy

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

4 BA as 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 and it was published here.]


Leave a Reply

Your email address will not be published. Required fields are marked *

3 × two =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”



To explore how we can help you, please get in touch