by Business Analysis,

To develop valuable software, inevitably, someone needs to understand the business needs and translate them so that someone can materialise it into an executable outcome. The focus for this blog will be on how the Business Analyst supports the role of the Product Owner of software development and delivery.

With the expansion of the agile culture, more than ever, business analysis is essential in the search for agile effectiveness. Understanding what will really deliver value to the customer and where that customer wants to go will give an excellent pace to an agile team. The business analyst provide insight many ways in a company that adopts agility.

Historically the Scrum Guide has not and still does not make specific mention Business Analyst as a defined role. Whilst, through experience in establishment and delivery we know the BA plays an integral role in driving agility in business and development teams, Scrum defines the Product Owner as the one who holds all responsibilities for a product being developed within Scrum. The Product Owner is the one who takes responsibility for the production flow and ensuring the delivery of the product/project.

As such, given the capabilities of both the BA and the PO, there is still some confusion about how these roles may coexist and provide the best value back to an organisation and product team.

Let’s present some definitions, to then analyse the differences, characteristics, and similarities between the roles to uncover how the Business Analyst and Product Owner can work together.

Definitions and Responsibilities

The Business Analyst

The Business Analyst has a broad list of required skills and knowledge, such as:

• Greater knowledge of the business structure.
• Understanding and articulating the company’s problems and goals.
• Value optimisation for the organisation as a whole.
• Working with stakeholders to map the value stream and customer journeys.
• Knowledge (or ability to gain) of the market and main competitors seeking a position for the product.

According to the BABOK (Business Analysis Bod
y of Knowledge), the definition of a Business Analyst is:

“A business analyst is any person who performs business analysis tasks described in the BABOK® Guide, no matter their job title or organizational role. Business analysts are responsible for discovering, synthesizing, and analysing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders. The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes.”

Therefore, the Business Analyst’s scope of action is the entire value stream within business being affected by the change. Business Analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders. They contribute to organizational improvement in the context of creating software products, improving business processes, business strategy, etc.

The Product Owner

Let’s take a look at it according to the definition of the Official Scrum Guide:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible and understood.

http://scrumguides.org/scrum-guide.html

The word to highlight here is PRODUCT. And, according to the Scrum Guide, the Product Owner’s mission is to maximize the value of the product. Therefore, the scope of action of a product owner is the creation/maintenance of software products. In this context, the product owner is responsible for representing the different interests of the organization’s stakeholders regarding the software product.

It is an extremely creative function, but also analytical. It’s business, but it’s also technology. It seeks commercial success, but also the best experience for the end user. When we look at the product management cycle more broadly, we understand that there are phases of conception, development and optimization, and the Product Owner needs to understand and improve on each of them.

Is there a Business Analyst in an agile context?

The Scrum Guide identifies 3 different elements: the Development Team, the Product Owner, and the Scrum Master. The Scrum Master is the one who oversees the process and eliminates impediments. The Product Owner is responsible for the backlog and for making the team understand what needs to be done. And the Development Team is the one that codes, tests, and delivers the product.

Note that at no point does the Scrum Guide speak of a Business Analyst role. It also doesn’t talk directly about UX and/or UI designers, Solution Architects, DBA’s and so many others that are obviously part of the development team. Therefore, and following the same logic of reasoning, nothing prevents a business analyst from being part of the development team and, as we will see later, acting as a support or pseudo product owner or even being the Scrum Master.

Then again, when examining the SCRUM Guide the reader will come across the following two astonishing statements about the development team:

“Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.”

and

“Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.”

When Scrum Guide says that it does not recognize any title other than Developer, is it not saying that there is no room for business analysts. A development team doesn’t just consist of developers only. Developer here is not synonymous with programmer. A developer is someone who develops something, so here at Scrum, we look at all team members as developers, and the business analyst is one of them.

In Scrum, sub-teams dedicated to a specialty are avoided, that is, we avoid the testing team, the DBAs team, the business analysis team and why not, team as a whole is cross-functional. It brings together all the skills to create the software product. EVERYONE is a developer in the sense that they are responsible for creating the product and not just a part of it. A collective responsibility and therefore by all existing under the one banner there is no one to blame, no fingers to point, we win together, we First. Attempt. In. Learn(ing) – together.

So, let’s see the possible configurations of the Business Analyst in an environment that uses the Scrum framework.

The Business Analyst in the Scrum framework

• Business Analyst in the Development Team: This is perhaps one of the more common configurations of the business analyst in Scrum. Because the Scrum Guide does not mention in detail each role in the Scrum team, so, we can have the business analyst as one of the team’s components. Having the analyst working side by side with the developers “remembering” what value means to the business, will enable the Scrum team to work with shared business goals.

In this scenario, the business analyst not only acts as the great articulator of the vision, but it also acts as a support for the PO in several other tasks, such as managing the backlog, with a focus on both the user and the organization.

Business Analyst as Product Owner: Playing the role of the Product Owner. The business analyst uses all their knowledge to help build the software product and manage the Product Backlog. Strong collaboration skills, enables the business analyst to move more easily within the organisation articulating the necessary resources to create the software product that really meets the customer’s needs.

Although the Scrum team gains a lot from the rich contributions of the business analyst during the software development, it is worth remembering that the scope of action is the entire organisation, and not just in IT. A Product Owner should have good business analysis capability, but the BA shouldn’t replace the Product Owner as this may create a conflict of interest in decision making.

• Business Analyst as a hub between the business and the Product Owner: The product owner, despite representing the business, does not always have the desired experience, maturity, and analysis capabilities. In this case, it works well when we have a business analyst on the business side assisting and supporting the Product Owner. The Business Analyst gives essential information about the organization and users’ needs to the Product Owner, where they can work together to develop the product based on the organization’s strategic objective. The team gains from the most assertive contributions from the business analyst in the product development. This often works well in larger teams where a Lead Analyst role can be applied to no disrupt the flow of the development team.
• Business Analyst as User: This model is very similar to the previous one, but instead of supporting the Product Owner in their function and also being a contributing member of the development team, the business analyst is consulted by the Product Owner and development team. They act in many ways as part SME/Part BA. The issue of conflict of interest may not occur here (depending on the ability for this person to understand the business value); however, as a User, the analyst may then not have the full commitment and time for the definitions of the product with the PO and development team.

The Business Analyst and Product Owner are different and complementary roles. But there are other considerations important to emphasise.

The belief that in agile teams there is no Business Analyst results in teams with a long and slow learning curve. The SDLC is still Analyse, Design, Build, Test, Release. The skill set in analysis is key, and an exceptional business analyst holds this skillset like no other. Business analysis helps shorten learning curve. Business Analysts use their knowledge in all areas of assessing business value, not only to support the Product Owner in the refinement and in the identification of new stories and acceptance criteria, but also to help the others in the Development Team ensuring a value stream within the team across this SDLC.

The Product Owner is a role played in the Scrum framework. While the Business Analyst is a role dedicated to improving the business, being able to act in the most varied initiatives in the organisation.

Business Analyst isn’t just a role, it’s a competency that virtually everyone in the organisation should develop (to some degree). More and more business analysts should understand the importance of this skill set in agile transformation and delivery, and push themselves to be leaders and agents of change in agile organisations.