Introduction

People on the internet, or even some clients, often question the exact role of a Business Analyst and Product Owner in a project. In some discussions people quote the official IIBA or Scrum guidelines, meanwhile, others present real-life experiences from their projects. 

The truth is that it is hard to draw the line. Both positions share similar roles due to the overlap of skills and responsibilities in the collaborative and Agile nature of the projects.

As a matter of fact, many BAs or POs of a project ARE one person. That’s the whole point of Agile values and principles, that they don’t restrict anyone from doing anything. Nevertheless, let me show you what I understand are the specific roles of a Business Analyst and Product Owner.

The roles of a Business Analyst and Product Owner

Business Analyst

A Business Analyst acts as the bridge between business ideas and business capabilities. They play a vital role as they help decode the future of businesses, by identifying, creating and scoping valuable changes and enhancements to business processes.

A brilliant Business Analyst:

• Makes sure that requirements are correct from the start
• Helps clarify product vision and understand business side needs
• Helps to understand the scope of the project (by workshops, meetings etc.)
• Supports the technical implementation
• Helps to estimate the time and costs behind the project
• Creates technical documentation without which development work cannot begin

Product Owner

Product Owner is an integral part of every scrum team. They represent the customer to the development team and are responsible for maximising the quality of its products. They are responsible for the entire development process - from business strategy to product design. Its role is to find a balance between business and technology.

Product Owners must:

• Define the project's vision by creating a product roadmap and communicating with stakeholders to understand business objectives.
• Prioritise needs and objectives of stakeholders
• Manage the product backlog, prioritise items based on strategy and map out dependencies.
• Work with the team and contributes to each stage of the development process.
• Anticipate clients' needs by understanding their market and creating customer journey maps.
• Act as a primary liaison, and evaluate and inspect the product progress through each iteration.

What to avoid in a project as a Business Analyst or Product Owner?

The main goal of working in Agile is to help teams deliver value to their customers faster and with fewer headaches. So how to avoid these headaches? What kind of rookie mistakes are not acceptable from a Business Analyst or Product Owner?

1) They don’t spend enough time on Product Backlog Refinement

Improving the Product Backlog Refinement aims to prepare the items/objectives at the top of the backlog for implementation in the upcoming sprints. It is natural that in an Agile project we need to know what exactly is to be done in a given requirement, be sure that we have all the necessary resources and means, and whether we will be able to do this work in one Sprint. The backlog needs time and needs to be improved on an ongoing basis.

2) Sometimes they don’t know their roles and their responsibilities

The essence of Scrum is self-organisation and cross-functional work. Although team members may have their set job titles, in such an environment there is a minimal definition of responsibilities and accountability. Minimum doesn’t mean there is none at all, so a BA or PO should: 

• Understand their place in a project
• Ensure transparency of their work
• Empower the people closest to the work to do what’s needed to solve the problem.   

3) They don’t understand what MVP really means

Many new products don’t get off the ground due to an early mistake - not understanding the MVP. Most importantly, unlike a prototype, an MVP is not only used to test design or technical. The main purpose of the MVP is to test fundamental hypotheses for your business model. Keep it simple, don’t overload it with features, don’t oversize it and implement an adequate project development strategy,

4) They don’t understand the business model

A Business Analyst or Product Owner should understand the mission, identity, personality, story and industry of their client. Each business model has its unique set of features that requires a similarly unique approach to the project.

5) Doesn't know how to reach customers/developers.

“Communicate continuously and clearly” - one of the fundamental principles of Agile

Poor communication is often cited as the biggest single cause of project failure. Honest and open communication can often solve many problems instantly or even avoid them at all. 

6) Does not know how to create documentation

There's little reason not to integrate the documentation effort as part of an Agile process. It should follow principles such as:

• Document everything that can be useful for others in future, so this way you can file what you have actually done/built and that way knowledge will not be forgotten.
• Simplify your work, write it in bullet points, and be concise. No one wants to go through dozens of pages of waffling. 
• Make sure team members contribute to the documentation effort. Gather information from developers, and engineers and include their figures or feedback. 
• Avoid overlapping documents, as it can cause chaos. You may end up with multiple pages describing one topic in various ways.

7) Does not know the principles of SCRUM / AGILE / WATERFALL / KANBAN

Everything I mentioned above is related to Agile and Scrum, which only confirms the need to know their basic principles. Without understanding them all of the efforts could go down the drain. 

What mistakes do clients make when working with a Business Analyst or Product Owner?

Working on a project with a Business Analyst or Product Owner requires two-way communication and an understanding of the common working ground. Clients may also make the mistake of misinterpreting the role of a Business Analyst or Product Owner. Such misunderstandings include:

1) They do not trust the Business Analyst whose goal is to know and understand the needs of the business side

Business Analyst constantly builds trust with their clients due to their consulting role in a project. As far as building trust goes, confidence must also come from the client’s side. Without the needed trust it does not matter how much hard work is done as it will not be regarded as good and effective.

2) They are not honest, they conceal certain facts and thus the Business Analyst and Product Owner do not have a broader context

Similarly to the previous point, honesty is the key to a common understanding. To envision the goals, the client needs to provide data, facts, and needs. Sometimes clients do not know their numbers or needs, and that’s absolutely fine! Saying “I don’t know” is acceptable and it motivates the team to find the right answer.

3) They do not cooperate often enough or are too closed off. 

Working with Business Analysts and Product Owners requires a lot of time and constant communication. During each stage and each sprint, clients must cooperate and be available if any problems arise. 

4) They hope for a ready solution to the problem

'Business Analysts and Product Owners are not wizards and do not come with ready solutions.'

Each project has its own needs and requirements, there are no ready solutions by default, only tailored solutions. Tailoring and adjusting these solutions requires many meetings, workshops, and studies. 

5) They are too strict and do not make compromises

What if the client’s idea cannot possibly work? This could be disappointing, but some projects may be well above clients’ heads. Clients need to accept compromises and allow Business Analysts and Product Owners to come up with accessible solutions. 

6) They want to work in Agile without following basic rules, such as the Agile Manifesto

Business Analysts and Product Owners devote themselves to understanding Agile rules. So should the client. Before starting a project, learn about the principles of the working method you will practice in the project.

Conclusion

The boundary between a Business Analyst and Product Owner is flexible and adapts to the situation, type, and size of a project or organization. This fact allows the Product Owner, Business Analyst and Scrum Team to work closely together and develop their skills.

However, there are projects where the role of the Product Owner is taken over by a Business Analyst, and vice versa. Can every Analyst become a Product Owner? No, not everyone for sure. But everyone can do their job in such a way that it brings the most benefit to all stakeholders.

As a present or aspiring Business Analyst or Product owner, make sure to follow the “dos and don’ts" to ensure the success of your projects. The same applies to clients who wish to deliver the finest projects with the help of the two 'heroes'.