The Business Analyst Role in Agile Teams

The utopia of purely Agile Teams

If you are now working in Agile and, in the past, you were working in Waterfall. And I will tell you something you might have already noticed. The two methodologies have a completely different perspective on business analysts.

In Waterfall, the Business Analyst (BA) role is very important. The BA is one of the core project members. However, in Agile methodologies, since they focus in software development, there’s not such a clear mention of the BA in the team (only the roles of Product Owner, Scrum Master, and Development Team are referred).

What I noticed since I started working under Agile principles is that there’s no clarity of how BAs interact and play their role with and within development teams, and whether the Product Owner sort of replaces the BA.

The reason for that might be that people mix concepts and terminologies between Agile and Scrum. Agile regards to the working principles. On the other hand, Scrum is one of the most known software development methodologies upheld in Agile principles. Or it can be because maybe are not able to apply fully all of the Agile “rules”.

When companies opt for a software development methodology leveraging Agile principles, such as Scrum, they might fall into one “trap”. They often try to strictly apply the guidelines and roles stated in that methodology, disregarding for their specific context, the needs of the project team, the organization itself, and their overall business analysis.

In fact, when looking for instance to the development teams themselves, they sometimes chase Agile concepts and guidelines way too ambitious, and state situations that don’t really happen in a company. Thus, they end up creating the utopia of purely Agile teams or better said Scrum Teams.

All in all, as you can see, working under the Agile methodology is not always a piece of cake! So, let me tell you about the challenges I have witnessed more often when applying Agile concepts and guidelines to software development projects. Of course, not all projects and teams setup are the same, but these are the ones I can see more often.

Agile Methodologies challenges

1. User Stories should be provided by the business or the Product Owner

• The details of the requirement are rarely enough when provided by end-users or business stakeholders, they often don’t know what they want or how best to achieve it.
• The Product Owner (PO) is usually not trained or doesn’t have a full allocation to write proper User Stories (US) ready to go straight to the development teams. POs are typically busy business people with plenty of other responsibilities, making it hard for them to handle all the demands and needs.

2. Business requirements need to be broken down into User Stories that represent a system feature from an end-user perspective

• A complex business requires extensive analysis to identify the required rules, processes, data, etc, that will not fit in the widely accepted smaller packages of Agile development.
• Getting to a list of smaller US that correlate and are dependent on each other, being part of a bigger picture, requires analysis, backlog refinement, and process and data mapping skills, that don’t come easy on anyone, especially not a PO or a development team.

3. The Product Owner and all the relevant stakeholders are available throughout the Sprint for project needs

• As mentioned already, POs and business stakeholders are often very busy and have other primary responsibilities. Therefore, they are not available as quickly and promptly as necessary for all the questions and required iterations with the development team to define the boundaries and rules of all those requirements.

4. Agile teams should be self-organized and cross-functional

• This assumes that the development teams are able to do the analysis, design, development, and test, in close contact with PO and sometimes the business directly. If so, development teams need to have a great deal of management, leadership, and soft skills to be able to manage alone.
• We have come a long way from the stereotype that developers don’t have communication and management skills, and we now give them space and training to allow them to grow. However, my experience is that it’s an overstatement to assume that all developers can have such skills and can elicit requirements effectively.
• Without BAs, the development team will likely have a gap of expertise, business knowledge and ability to perform business analysis and manage stakeholders.

The Business Analyst role

The role of a BA is often questioned within Agile methodologies, not on the quality of the work, but the “perceived” value delivered for the team. So, let’s start by truly understanding what it means to be a Business Analyst.

The Business Analyst in system projects is typically someone that:

• Helps the customer identifying and defining the problem;
• Elicits business rules and processes;
• Defines and documents requirements.

In more practical terms, the BA will talk to the business stakeholders, bring alignment between management and end-users, break down complex problems into workable bits of a solution, get answers quickly, represent stakeholders, identify impacts and dependencies, test and validate, be at the center of the communications between every involved party to help the development team, and keep up with all the changes and priorities.

Moreover, on one hand, business stakeholders are busy people, with tight agendas, often accumulating different responsibilities that make it hard for them to make themselves available. On the other hand, development teams typically have questions that business users struggle to understand, and they require multiple interactions throughout the delivery time-frame, which means, they require business answers promptly to make the most out of their time. This is where the BA comes in and plays a critical, fundamental role.

To say the least, a BA has a collaborative profile and works closely with the team and the customer throughout the project ensuring alignment between the business needs and the development team.

How can a BA help in Agile teams?

First things first. Agile methodologies don’t define many roles, mainly because it would work against one of its key foundations, collaboration. Focus on collaboration makes the definition of many roles unnecessary. But as wonderful as Agile is, it doesn’t represent a business analysis process, it does represent a software development process focused on delivering as much value as possible to the business.

Agile teams still need to:

• Find what is the business need or problem and determine what changes will have the most value to the business;
• Collaborate with business stakeholders across the organization and gain alignment;
• Understand the wider context and inner inter-dependencies, so we can deliver with maximum efficiency.

Plus, BAs have always been agile – we adapt, innovate, accept change, have leadership and empathy skills to manage stakeholders, and are business-oriented to get the added value.

Of course, if companies and project setup allow having a PO fully dedicated to the team, able to write US with the necessary detail (that bring the intended value to the business), and that can be present in all the meetings and interactions the development teams needs, then probably we don’t need a BA. The issue is that most of the time, it’s not possible to meet all these conditions because of the challenges I mentioned before. So, I cannot empathize enough how finding in your company or project what are the handicaps and gaps in applying Agile methodologies guidelines is crucial. It helps you determine what is the best setup of the Agile team that would work for you.

In which areas are BA key within Agile methodologies?

Now that you have seen the role and characteristics of a BA in Agile teams, I will tell you in which areas they are key:

1. Define and document User Stories

The Agile Principles of “Working system over Documentation” and “User Stories over complex solution requirements” might look good in paper but it’s not easy to understand what minimum level of details is required in a US to get a development team to work and to deliver the intended value. It’s different for every company and the BA can work with the PO and the team to find the best balance and define what and how to document.

2. Backlog Refinement & Prioritization in collaboration with the PO

The system often serves many stakeholders with different profiles and objectives, and every business requirements need to be evaluated on the overall benefit and priority. So, it’s ultimately a PO’s responsibility to approve User Stories and prioritize them in the Backlog, weighting each individual US’s value to the overall organization. BAs can play a fundamental role in helping the PO with these responsibilities, in keeping the backlog well organized, groomed, and prioritized.

One way to help refining the Backlog is to have BAs, in a first instance, defining with the end-users and business stakeholders requirements into User Stories and Acceptance Criteria. Secondly, they can collaborate with the PO to get his/her approval of the US, confirming the business value of each and every one of them and prioritize them individually.

Communication skills and the ability to collaborate and work with the PO and the team to get to a common understanding of US value, scope and acceptable scenarios from the end-user perspective is crucial and commonly found in a BA.

3. PO’s Proxy

According to Agile methodologies, POs should be present in daily stand up meetings and any questions from the development team should be asked to the PO for clarification. However, as one of the main challenges we have discussed is PO’s busy schedules, often they don’t have the necessary availability.

Thus, one common solution found for PO’s unavailability is to have the BA as a proxy to product owners and business stakeholders on daily interactions and simple questions/issues, under the assumption that their initial analysis has given BA’s the necessary knowledge and context to answer. That’s not how Agile defends it should be, but that’s how we can get things done more quickly and effectively, as Agile also defends.

Besides, with time, POs becomes more comfortable with BAs’ decision-making and overall understanding of the business and could give them more autonomy for such decisions. Similarly, development teams will recognize the more and more BAs as trust-worthy for most day-to-day questions about User Stories and related product decisions.

4. Other contributions (depending on each business’ needs and context)

• Support development: BAs can assist or play a lead role in many of the product discovery activities, including qualitative and quantitative data analysis, opportunity assessments, designing product experiments which will then support development teams’ work.
• Change Management: With the acquired business knowledge and end-users’ daily routines, BAs can help to outline plans for Business Change, and Training to support users on the transition and boost adoption.
• Coaching: Agile BAs can be leaders who communicate and collaborate effectively with different team members and stakeholders and guide them to achieve common project goals.
• Ability to multi-task: BA’s can also play other roles on the project according to the project needs, such as QA or Tester given their acquired business knowledge.

Summing Up…

Summing up, in Agile methodologies you still need business analysis. However, it’s true that you don’t necessarily need the designated role of Business Analyst.

In my opinion, it is best and more efficient to find how, in each company, the BA’s role would fit the process and team to deliver maximum value, rather than not having a BA at all and rely on the PO or the development team to do all the business analysis activities.

In fact, the overall approach we have been taking in our customers in terms of the BA role is that the BA will work on business analysis and User Story writing prior to the Sprint as part of Backlog Refinement. Then, he or she will play a supporting role in the development team throughout the Sprint itself.

The BA role will vary from team to team and from organization to organization, but the real change is in the approaches and deliverables, not in the activities itself. So get ready to find your best BA fit!

I hope this article has been useful for you to understand better what Agile is all about and which role business analysts play under that methodology! If you have any doubt about it, ask away! 🙂

x

SUBSCRIBE KNOWLEDGE CENTER