#Product Owner #Business Analyst #Software #development
The role of the Product Owner and Business Analyst in the software development process
Do you recall a situation in the project when the Product Owner living on the other side of the globe did not answer your questions all day? Or maybe you are a Product Owner who wants to talk to the team about new functionalities, but the developers are exhausted after a day of work or have not woken up yet? If you answered “yes” to any of these questions — you probably know that these scenarios can cause some serious problems in delivering the product before the deadline. But you know what? A Product Owner can help! If you wonder what the role of the Product Owner in software development is — this article is for you.
Responsibilities of Product Owner (PO)
Let’s recall what the role of the Product Owner is characterized by and what is the basis for the organization and project.
The daily tasks of the Product Owner are:
- representing a group of stakeholders and clients,
- taking care of a clear vision of a Product Goal,
- creating a product goal implementation plan and responding to changes,
- making the final decision as to the sequence of execution of individual items in the product backlog,
- establishing metrics that will be helpful in controlling the chosen road.
As you can see on the list above, one of the most important responsibilities of the PO is to create a plan. When using Scrum, your project plan is a Product Backlog that contains a list of tasks that need to be performed in order to achieve the assumed Product Goal. It is worth noting that the Product Owner is the only person who manages this list. Of course, they may ask someone to do that or allow other members of the Scrum Team to add items to this list, but anyway they decide the order of tasks.
Product Backlog management is a very important activity in the everyday Product Owner’s job because a well-kept list has a positive effect on building transparency and trust in the team. When the list is in an easily accessible place and at the top of the list are the tasks with the highest priority and already well detailed, then Developers can easily see what tasks will be performed next. Another feature of a well-managed Product Backlog is the so-called “bigger picture” — this list should show a broader view of what will be done later.
It should also be recalled that the Product Owner is the only decision-making person for the development team. According to the Scrum Guide:
Nobody can tell the development team to work with a different set of requirements, and the development team must not take action based on what other people say.
In order for all the above to take place, it is necessary to ensure that the Product Owner has enough time to devote themselves to these duties and is available to developers in case they have questions about their ongoing or future tasks.
Theory vs reality
The theory is one thing, but it’s more important how it all works in reality. Personally, I have experienced different involvement levels of people in the role of Product Owner. You may be tempted to define a certain pattern that the larger the company is — the smaller the availability of PO may be.
On one of the websites about Scrum, you can read that “business people which have the “MAN” (Money, Authority and Need) are usually too busy to also deal with time-consuming activities such as detailed backlog management and requirement definition. That may make this new role (PO) not so attractive to those business roles, which could be the ideal Product Owners” (more on that can be read on the Scrum.org website).
This is one of the situations that may arise. Another challenge may be working in other time zones. When the team and the Product Owner are in a different time zone (when the time difference is more than about five hours), there may be a situation where points of contact between them and the development team may be few, which may affect the pace of work.
Let’s imagine that developers start work at 8 AM in their time zone and encounter some ambiguities in the task description or any other complications. They would like to discuss possible solutions with the Product Owner, but they have to wait until the PO comes to work because in their time zone it’s 3 AM. This is a real problem in the organization of work that can destroy even the best plan. Of course, the ideal solution would be for the Product Owner to work in the same time zone, and it would be even better if they were physically in the same place as the team. It is clear that in the current pandemic situation, most of us work remotely, but there is still a more accessible person who works in the same structures rather than someone in another organization.
The question we should now ask is: what can you do to reduce this type of risk? Fortunately, we are not the first to face such difficulties, and we can benefit from the experiences of the others.
What about the Business Analyst?
Anybody who likes to create and manage documentation — raise your hand, please. Maybe there is someone who likes to write it, for example by creating User Stories? To do that, you need to add Product Backlog management, answer questions about functionality and potential solutions, analyze stakeholders and manage them in an appropriate way.
Probably not many of you like it, so finding a willing person to become a representative of the Product Owner can be a real challenge. However, there is a role that has similar responsibilities when working on a project. It’s a Business Analyst.
The scope of Business Analysts duties very often includes:
- gaining knowledge about the client’s domain,
- getting to know the current processes in the client’s organization,
- analyzing the stakeholders,
- getting to know the purpose of the project and the final state you are aiming at,
- describing and managing the requirements,
- verifying and validating requirements with stakeholders.
The Business Analyst focuses on transforming the question “why?” into “how?” by working with the development team or analyzing the competition and the market.
As the research conducted by the IIBA (International Institute of Business Analysis) organization shows, 35% of analysts working with Agile methodologies already perform tasks related to the role of the Product Owner. A Business Analyst seems to be an ideal candidate to become a Proxy Product Owner.
The Product Owner has the decisive opinion on the direction of product development as well as setting priorities.
However, remembered that in the absence of sufficient availability for the team, for various reasons, the emergence of the role of the Product Owner’s representative may significantly improve the pace and smoothness of work. You should not be afraid to use this type of help.