Star Wars & Scrum Teams (Part I)

In this blog series, Oleksandra Skybina (Project Manager & Agile Practice Head) and Andrii Kulshan (Business Analyst & Product Owner) from GlobalLogic’s Kharkiv engineering center discuss the structure and roles of an Agile Scrum team.

In a galaxy far, far away, a group of unlikely heroes were building the most advanced product of their time: the Death Star. Ok, so Darth Vader’s imperial engineers aren’t exactly the heroes of the Star Wars saga, but they do illustrate a great example of how a Scrum development team operates — along with the stormtroopers and the officers who respond quickly to the changing demands of the Emperor (aka, Stakeholder) that are provided to them by Darth Vader (aka, the Product Owner) and his assistant, who we are calling Mini Vader (aka, the Business Analyst). In Part I of our blog, we’ll analyze the roles of the Product Owner, Business Analyst, and Stakeholders.

Product Owner

The Product Owner (PO) is a person who acts as a client representative and presents the results of the Dev team’s work. Anyone can serve as a Product Owner: business owners, testers, business analysts, etc. As shown in the above figure, the Product Owner’s area of responsibility is the final product. Their tasks include:

Managing the Backlog: The PO decides what will go into the backlog (i.e., a list of tasks) and what will not, the priorities of the tasks in the backlog, and the value that the solution will bring to the business.

Defining the Minimum Viable Product (MVP): The PO identifies which part of the product can be delivered to clients and end users in the shortest time with a minimum set of features.

Participating in Development: The PO answers the team’s questions and participates in all Scrum events, including both daily rallies and so-called “backlog refinements,” where the PO describes tasks and business cases to the team, provides information for quality assessment, and collects feedback on system limitations.

Demo’ing the Product: The PO demos the product for the stakeholders at the end of each sprint and describes in detail the products functionality and compliance with business requirements. They are also responsible for training end users and writing documentation.

Saying “No” to Stakeholders: This is the most important aspect of the PO’s job, as they are the ones who collect claims from various stakeholders. Often, tasks and ideas are more than a team can accomplish in a realistic time frame. It is important not just to postpone, but also to completely reject some ideas. The PO must take into account business needs, user preferences, metrics, priorities of different groups, workload and specialization of teams, market trends ,and much more. We can say that this is almost the central task of the PO; based on their experience and knowledge, the PO must select the ideas that will lead the project to success. Some PO’s make decisions intuitively, but even in this case, they must be able to explain their “no” to all stakeholders.

Business Analyst

The Business Analyst (BA) transforms ideas into requirements. The role of Business Analyst is sometimes confused with that of Product Owner. The main difference is that BA is a profession, whereas PO is a role in Scrum. While the PO is responsible for the strategic direction of a product, the BA is responsible for the tactics used in developing the product. At the junction of these areas, the two roles intersect. It is not always clear who should write business cases, collect initial requirements, and communicate them to a team — especially in terms of outsourced products, when the roles are not what they seem.

In Scrum projects, the BA helps the PO specify the requirements. The BA can be either part of a team or a stand-alone unit; work with multiple teams; and describe the requirements for different modules or subprojects.

Of course, the role of the BA is not limited to the requirements management only. They can also communicate in the same way with stakeholders and users, analyze the market, and come up with hypotheses (although in an outsourced environment, this is not always possible). As shown in the figure below, we have identified several configurations of the BA and PO interactions, along with the division of their responsibilities.

Based on these configurations, you can better understand your own situation and how to build more effective interactions with the client. Let’s consider each configuration in more detail.

BA-PO-Client (Product Group)

The first configuration is perfect. We have the Business Analyst and the Product Owner, and we have the Client (Product Group). If the PO is also a part of this Product Group (i.e., can make decisions and influence the scope of tasks), then everything is fine. The BA specifies the requirements, the PO deals with strategic planning and says “no” to everyone. The client is happy and satisfied with both the system and the fact that the team is self-organized. With this configuration, you can offer the client a full, autonomous development cycle, from idea to implementation.

BA/PPO (Proxy Product Owner)-Client

This is a good configuration for starting a project where you do not yet have the client’s trust. Here, the client provides clearly defined business requirements for all stages of the project (i.e., roadmap) and a list of requirements (i.e., backlog) for each team. The BA, who also acts as the Proxy Product Owner, simply distributes these requirements and monitors their evaluation and implementation by the team. Over time and with good relations, this model of work can grow into the first option (i.e., BA-PO-Client), with more freedom for decision-making.

BA-PPO-Client

This is probably the least effective configuration because the chain of decision-making and requirements verification is stretched. Roughly speaking, the PPO is responsible for almost nothing, and the BA does not know what to do — whether it is possible to contact the client directly, or why he needs the PPO. Therefore, try to avoid this model.

BA-Client

In such a model of interaction, the ready-made requirements come from the Product Group of the client, and from your side the BA only helps to work out local functionality, constantly confirming each change. This model occurs when the client has almost no trust in the team.

PO-Client

There is the client, there is the Product Group, there is the Scrum team — and each team has the Product Owner. The PO receives the initiative from the Product Group, processes business cases and requirements, and communicates them to the team. With great decision-making freedom for both the PO and the team, there is no BA in this scheme, so the PO and the team must work together on the tasks that the BA usually performs. Not all teams are happy with the prospects of writing user use cases, so the introduction of such a scheme may be met with some resistance. A transition period from BA – PO – Client is often required, but a successful transformation increases both the efficiency of the whole team, and the quality of development. It also reduces the response time to any changes in business tasks.

To sum up, although the Product Owner and the Business Analyst are conceptually different, but in many tasks they intersect. To understand who you need on a project, you need to find out the client’s expectations, their level of trust in you, the needs of the team, and the degree of team autonomy.

Stakeholders

The term “stakeholders” is often found in a professional environment. You might think it’s a single person or a few people who always have the final say. This is often the case, but at the same time, this term includes almost all participants in the development, including:

Clients: These are the decision makers, delivery managers, and product managers at the client company. There may also be people in marketing or sales who can help us understand what needs to be done, find out what users expect, and provide market analytics.

Internal/External Users: Depending on what product you are creating, there may be not only end users, but a large group of professionals with ideas for improving the product.

Team: This is the development team that sees and improves the product every day. Many people make the big mistake of not listening to a team, but its opinion can be very valuable.

Miscellaneous: One example of a “miscellaneous” stakeholder is an external regulator. If you are in the medical or financial field, then your products must comply with regulations, rules, and laws that are often controlled by special organizations. You can also add internal regulators to this group, such as the legal department. They do not directly affect the functionality, but they may impose some limitations.

How can you understand how to work with each of these audiences? You can start with a Stakeholder Influence / Interest” matrix, like the one pictured below. It will help to determine where to take a particular group of stakeholders, and how to organize the process of interaction with them.

Manage Closely: This quadrant includes stakeholders who have a great influence and are the most interested in the product. You need to work with this group of stakeholders first.

Keep Satisfied: This quadrant includes stakeholders who are not particularly interested in the product, but have a great influence. These can be the same external regulators or heads of legal departments. You need to make sure that they are satisfied by adding the necessary functionality to the product.

Keep Informed: This quadrant includes stakeholders who are very interested in the product. They usually have a lot of ideas, but they have little impact on the project. They should not feel offended, so we have to inform them.

Monitor: This quadrant includes stakeholders who are not interested and have no influence on the project. However, it is necessary to look at them sometimes because they may suddenly pass into any of the other groups, or they express useful ideas.

In Part II of this blog series, we’ll take a look at the various roles and responsibilities of the Development team, including Scrum Master and Manager roles.