A Business Analyst of the 21st century – a fast track to a Product Owner?

More and more companies carry out their IT projects using agile management methodologies. Scrum is one of the most popular frameworks in which I have had the opportunity to work during my career. What is the role of a Business Analyst (BA) in Scrum projects? Can an analyst perform the duties of a Product Owner (PO) and take on this role? Let me tell you what it looks like based on my own experience with projects.

Theory vs. practice

Let me start in a non-standard way… with a warning. Are you a Scrum enthusiast and have studied the Scrum Guide several times, treating it as a kind of bible? If so, after reading my article you may feel as if you have bumped into a wall. My observations about working in agile methodologies presented in this text are not exactly the reflection of what the Scrum Guide says. Sounds intriguing? It’s time to give you more details.

Before we have a look at the similarities between the work of a BA and a PO, let’s revise the definitions of both roles.

Who is a Business Analyst?

Very often, you might come across the statement that this role is a kind of bridge between the IT world and the business. And what does our analytical bible, the BABOK Guide (Business Analysis Body of Knowledge Guide), say about it (yes, we, analysts, just like “Scrummers”, have our own bible!)?

The approach of the BABOK Guide is quite “agile”, saying that a BA is a person who conducts business analysis (according to the principles of the BABOK Guide), regardless of the position held in the organization. Of course, the market has also defined the role of an analyst and specified requirements for candidates. They are expected to have both hard and soft skills (I highly recommend the article on soft skills in business analysis “Soft skills of a business analyst”).

However, people in other positions also have a basic set of competencies to conduct a simple business analysis. These are, for example:

• Business Architect,
• Data Analyst,
• Product Manager,
• Requirements Engineer,
• Product Owner.

We have distinguished these specializations in the Business Analysis Department in response to the market expectations.  Coming back to the thesis I stated at the very beginning – why is it so difficult to define the responsibilities of a BA? The areas of analysis listed above help to understand this.

A Business Analyst mainly focuses on solving a problem by describing it within a process. They do not go straight into technical details or look for a solution in the form of an IT system.

A Systems Analyst is on the other end of the spectrum. It’s a person with a technical flair, with the ability and skills to analyze the problem from a more technical point of view. Therefore, they offer users support with an IT system.

A combination of these two specializations – a Business Analyst and a Systems Analyst – is the most common and universal. Specialists like that focus on business processes and possible areas for improvement at the beginning of the analysis. In the next step, they look for solutions, based on the implementation or adaptation of an IT system.

You can read more about how a BA works in the article “Business Analysis in IT project – who does the business analyst work with?”.

Regardless of the area of specialization, the natural predisposition of the person is crucial. The soft skills I already mentioned are the core of this role. We can say that they are the base for technical competencies. Natural qualities determine whether an analyst performs well also in the role of a Product Owner. But we will get back to this in a moment…

Who is a Product Owner?

Let’s see how the Scrum Guide defines the role of a Product Owner.

It says that the goal of all Product Owner’s activities is to maximize the value of the product. The result of these activities should be visible at the end of each sprint. The main responsibilities of a PO include managing the product backlog. They do it by:

• defining elements of the product backlog in a clear, understandable way,
• spreading the vision of the product,
• prioritizing tasks,
• optimizing work of the Development Team,
• making the backlog transparent and available.

Theoretically, Product Owners can perform tasks from the product backlog by themselves or delegate them to the Development Team (a much more common situation). However, they always remain responsible for the results of the team’s work.

In “pure” Scrum, only one person can take on the role of the Product Owner. I won’t go into the details of PO’s competencies – there are two articles on our blog that describe this role and its work tools: “Who IS NOT a Product Owner?” and “The basic tools of the Product Owner’s work.” What I have described so far is enough to make a comparative analysis of a BA and a PO.

The Development Team is responsible for implementing the backlog items (specified by a Product Owner, at least in practice). According to the Scrum Guide, the names of roles in a Development Team are not defined, and the team should be self-organizing and cross-functional. In reality, almost every Development Team has separate roles, such as a backend developer, frontend developer, tester, or BA. We can categorize each of them according to their level of experience. The most common hierarchies are junior, regular, and senior.

A frequent misconception that I have noticed in commercial projects is using the role of a Scrum Master as a kind of a Project Manager. Is this the right practice? I don’t know, my knowledge and competencies do not allow me to answer this question. I just want to point out that a Scrum Master is not only responsible for making sure that the product delivery progresses in the spirit of Scrum (in simple terms, of course). The portfolio of their duties often includes the following tasks:

• team setup,
• budget management,
• project timeline management,
• responsibility for the results of the team’s work.

We are getting closer and closer to the essence of the article – the differences between the role of a BA and a PO.

Business Analyst = Product Owner? Is it true these days?

I started my article by describing the basic duties of a Business Analyst (including specializations within this role) and a Product Owner. I wanted to show the fine lines between individual roles in IT projects and how easy it is to blur them.

I will emphasize what I already mentioned – not every analyst can feel comfortable in the role of a Product Owner and it is closely related to the predisposition and interests of the person. I have observed that people with a Business-System Analyst profile (the role that I already defined as the most universal) most often perform well as Product Owners.

The predisposition to perform this role is one thing, but what are our customers’ expectations?

When building a project team, the expectations set for the analyst more and more often coincide with those that the Scrum Guide sets for a Product Owner. If you can have two-in-one, why not?!

At Craftware, we try our best to respond to customer expectations and market demand. Our analysts who possess the necessary qualities to be Product Owners improve their qualifications in this field and confirm them with certificates. Thanks to this, customers can be sure that they cooperate with people who are competent to perform this type of task.

So what exactly do analysts do in projects?

• We elicit requirements.
• We document them in a form that is clear to all parties – business and the technical team.
• We understand the purpose of building a given system.
• We feel responsible for the final product and for the value of the product that we deliver with each iteration.

When we add to this a few techniques and tools that a Product Owner uses, we see that the line between these two roles is becoming more and more blurred. The Business Analyst of the 21st century from the title of the article is certainly prepared to take on the role of the Proxy Product Owner. Unofficially, it happens more and more often.