Agile methods were introduced in the late 1990’s to bring product innovations to market more quickly and deliver value to the consumer. Agile is rooted in a team-approach and defined by a set of principles and values. The Product Owner’s role on agile projects is to ensure the product meets the consumer and stakeholder needs. Their work includes market analysis, product vision and go-to-market strategy. The Business Analyst does not have a stated agile role. However, their expertise as facilitators and problem solvers can be invaluable to an agile team. Closer analysis of the product owner vs business analyst shows reveals project responsibilities and skills overlap between these two roles.
Product Owner vs Business Analyst on Agile Projects
The Product Owner
The Product Owner is often the primary interface to 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 often act as a gateway to funding, making the business case for additional funding, or they can be a powerful ally removing for roadblocks. They also manage the iterative development process.
The PO originated in Scrum (a defined agile methodology) but is also used in other agile and hybrid approaches. According to Scrum, the PO is the person responsible for maximizing the value of the product and the work of the Development Team. The PO is responsible for managing the Product 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
- Prioritizing the items in the product backlog to best achieve goals and outcomes
- Optimizing the value of the work the team performs
The Business Analyst
As we explored earlier, BAs are expert in elicitation and defining requirements. The BA’s analytical and communications skills help find and bridge the gaps between business to technical teams. Because BAs are trained in technical analysis and design, they can help with tasks such as:
- Splitting large stories into smaller ones
- Modeling workflows
- Modeling data
- Clarifying business rules
- Ensuring non-functional requirements are addressed
While the BA does not have the business authority necessary to be an effective product owner, they can be an excellent resource to perform the backlog management functions of a PO. They typically bring deeper technical skills, but shallower business knowledge.
Product Owner vs Business Analyst Overlapping Roles and Areas of Focus
BAs are often more project- and tactical-focused while POs are more focused on business strategy and the customer. Some of these overlapping views, roles, and skills are shown in the diagram below.
Personality and soft skills play a role as well. A collaborative BA or PO who lacks business knowledge or technical appreciation is better than a non-cooperative genius. When communication and collaboration stop, role definitions and skills are negated.
Common Product Owners vs Business Analyst Patterns
Let’s examine some of the predictable scenarios often play out on project teams.
1. Product Owner as Bridge
In this example, the PO plays the traditional role as dedicated and direct connector between the Business Community and the Development Team with no BA present. This role, when performed properly, delivers the benefits of effective backlog management and beyond backlog management benefits as well.
2. Business Analyst as Go-Between
Here, the direct connection from the Business Community to the Development Team is funneled through a BA. The BA acts as a filter reducing the flow of information to the Development Team and diluting the message through translation. It reduces the rich flow of requirement and business priority nuisances that occur through daily interaction. It also dilutes the message through translation. Avoid the BA acting as a go-between from the Business Community to the Development Team.
3. Business Analyst as Proxy Product Owner
Often a PO is only available sporadically, so a BA is assigned the role of PO. The issue? While a BA may be great at backlog management, they do not have the authority to:
- Facilitate contact with other business stakeholders
- Gain additional funding
- Find business advocates 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. While a BA may be able to play the PO role, it is not ideal and can lead to friction among teams.
4. BA as PO Supporter
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 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 the ideal world, it is best to have both skilled and personable POs and BAs available to project teams.
BA Skills on Agile Projects
While the PO and BA roles overlap, they are not synonymous or interchangeable. In the ideal world, it is best to have both skilled and personable POs and BAs available to project teams. Unchanged: While the PO and BA roles overlap, they are not synonymous or interchangeable. In the ideal world, it is best to have both skilled and personable POs and BAs available to project teams.
Consider these ideas and diagrams as tools to help determine the best use of people in your unique organization and project. Use them to start conversations with stakeholders about roles and responsibilities. Try the roles, then inspect and adapt the approach based on your results. The good news is that agile environments provide quick cycles to evaluate experiments and changes. Unchanged: Consider these ideas and diagrams as tools to help determine the best use of people in your unique organization and project. Use them to start conversations with stakeholders about roles and responsibilities. Try the roles, then inspect and adapt the approach based on your results. The good news is that agile environments provide quick cycles to evaluate experiments and changes.