What Is the Role of the Business Analyst in Agile?

The Business Analyst helps the agile team to elicit, analyze, and capture business needs and customer requirements. Here’s how.

Published

One of the biggest misconceptions people have about agile are related to the domain of business analysis (and the Business Analyst’s role).

It all starts with the second value of agile in the Manifesto for Agile Software Development (agilemanifesto.org), which says that agilists value “working software over comprehensive documentation.”

Does that leave the Business Analyst without much to do in an agile organization? If they don’t generate comprehensive documentation, what is it exactly that they’re going to do?

You’ll be surprised. In this post, I’m going to talk about the role of the Business Analyst in an agile project—and just how important to a team’s success that role can be.

So, what is the role of the Business Analyst in agile?

In an agile project, the Business Analyst works as a member of the team, helping to translate business requirements into user stories and acceptance criteria on the product backlog, as well as ensuring that the product and sprint backlogs are well refined and kept up-to-date.

An experienced Business Analyst can be a mission-critical team member, setting the templates and approach for how user stories and acceptance criteria are written, and working with their teammates to improve their understanding of the business domain and customer needs.

This is especially true for newly-formed agile teams, who are early in the Tuckman stages of group development and whose individual members have yet to gain experience in working with an agile approach. The experienced Business Analyst can help to teach others how to elicit and capture business requirements in an agile way, using “just enough documentation.”

The Business Analyst is the expert on and the promoter of agile analysis techniques within the agile team. This includes, but is not limited to, understanding the business domain and customer needs, visualizing value streams and user journeys, writing and mapping user stories, and formulating acceptance criteria.

Agile teams that have a Business Analyst onboard are more likely to build products or services that meet customer needs and drive greater business outcomes. If a Business Analyst is not available, at least one member of the team should have experience in business analysis.

What Business Analysts Do in Agile

In an agile project (no matter which agile project management framework is being used) the Business Analyst works as a member of the agile team, helping the team’s members and its stakeholders to:

  1. Understand the business domain and customer needs behind the product or service that they’re building;
  2. Facilitate the collection of requirements and ask questions that help the team and its stakeholders get to the necessary level of specificity;
  3. Identify what needs to be built, in what order/sequence or criticality/priority it needs to be done, and what acceptance should look like;
  4. Set the best practices for agile analysis, create examples, and spread the knowledge for how to elicit, analyze, and capture requirements in an agile way;
  5. Describe the external and internal context surrounding the product or service that’s being built and how it relates to the work being done;
  6. Set the standards, templates, and approaches for how business requirements are elicited and captured on the product and iteration backlogs;
  7. Refine the product and iteration backlogs. Create, edit, or archive work items;
  8. Map epics, features, and/or user stories to release versions during release plans;
  9. Teach, coach, mentor, and facilitate the stakeholders and the team when it comes to formulating business needs and identifying business requirements.

The Business Analyst contributes an agile analysis mindset to the agile team. They come in with useful approaches and valuable skills that they share, through their day-to-day interactions and work, with the rest of their team’s members.

Is There a Business Analyst Role in a Scrum Team?

No, there isn’t a Business Analyst role in a Scrum Team. In a Scrum Team, there can only be a Product Owner, Scrum Master, and Developer. But a Business Analyst can be a member (therefore a Developer) of a Scrum Team—even if they don’t do programming.

Teams that use Scrum, the most widely-spread agile framework, are often confused by the role of the Business Analyst. This is because the Scrum Guide (scrumguides.org) prescribes only three roles in a Scrum Team: the Product Owner, the Scrum Master, and the Developer.

It’s important to remember that Scrum is a lightweight framework and the Scrum Guide is purposefully incomplete. Even though Scrum started as a software development framework, today it has become a product development framework for software or non-software projects.

When using the term “Developer,” the Scrum Guide refers to any member of the Scrum Team who is not the Product Owner or Scrum Master and who is helping to develop the product by creating any aspect of it during the sprint.

But don’t take my word for it. Here’s how Jeff Sutherland and Ken Schwaber, the founders of the Scrum framework, along with their most senior Scrum Trainers from Scrum Inc. and Scrum.org, explain the 2020 update of the Scrum Guide (and the role of the Developer in the Scrum Team):

In other words, the Business Analyst—like the Software Architect, UX Designer, Quality Assurance, DevOps, or Site Reliability Engineer—can be a full- or part-time member of the Scrum Team.

The Business Analyst can also be the Product Owner. More often than not, the Business Analyst and Product Owner are roles played by two separate individuals who work together with the Scrum Team and its stakeholders and share shared responsibility over the product and sprint backlogs.

The Product Owner is accountable for maximizing the business value of the Scrum Team’s work. This is why they have the final say on the contents and order/priority of backlog items. However, they can choose to delegate some or most of these responsibilities to the Business Analyst (and make decisions only when trade-offs are needed).

Personally, I like to look at the Business Analyst in a way that’s similar to the Scrum Master. The Business Analyst is there to teach the team in agile analysis and facilitate the elicitation and capturing of business requirements from their stakeholders.

Ultimately, they should make themselves redundant for the team by setting the best practices, spreading knowledge, and teaching them the agile analysis mindset—so that they can move on to doing the same for other agile teams that need it.

Another way to look at the Business Analyst is as the future Product Owner. In organizations that use the Scrum@Scale framework, for example, a Product Owner can progress to the Chief Product Owner role as part of their personal development plans. Which makes the Business Analyst on the Scrum Team the best candidate to take over their product ownership accountabilities.

The Typical Day of a Business Analyst

On a typical day, the Business Analyst who works as part of an agile team attends the Daily Scrum meeting. They share with the rest of their team members what they worked on yesterday, what they’re planning to do today, and whether or not they’re facing any impediments along the way. They seek out opportunities to help other team members in case they have questions or needs related to user stories on the active sprint or product backlog.

The Business Analyst works with the Product Owner and Developers on the Scrum Team to create clear and actionable user stories, and elicit acceptance criteria in a usable and testable way. For example, if the team is practicing Behavior-Driven Development (BDD), the Business Analyst elicits and formulates acceptance criteria in the Given-When-Then (GWT) format.

On different occasions throughout their day (like on email exchanges, ad-hoc meetings, recurring routines), the Business Analyst partners up with the Product Owner and interacts with the stakeholders to elicit and capture business requirements in the product backlog. These requirements come in at various levels of readiness and require varying degrees of analysis.

It’s not uncommon for the Business Analyst to create “just enough documentation” that helps the rest of their team members digest complicated requirements from customers, organizational policies, and/or external regulations and industry standards—which the agile team needs to take into consideration when building the product or service.

The Bottom Line

The Business Analyst can play an important and mission-critical role in an agile project.

As the owner of the agile analysis process, the Business Analyst drives how business requirements and customer needs are elicited, analyzed, and captured on the product and iteration backlogs.

The Business Analyst also helps the rest of the members of the agile team to adopt an agile analysis mindset and approach, applying the principles of “just enough documentation” using visual diagrams, plain language, and good ol’ common sense.

On projects with a high degree of complication because of specific external or internal requirements that the agile team needs to adhere to, the Business Analyst acts as the “Chief Clarity Officer” and helps the Product Owner and Developers on the team to digest what needs to be done (and how, so that it conforms and complies to the specific requirements).

The experienced Business Analyst is a little like a Scrum Master. They come into the team and facilitate the business analysis process, spreading their mindset and approach to each and every team member until their services are no longer needed. Once the agile team has become self-sufficient, the Business Analyst moves on to another agile team.

By Dim Nikolov

Jack of all trades and master of none. Dim is a Certified Scrum Product Owner (CSPO) and Certified Scrum Master (CSM). He has a decade of experience as a stakeholder, member, leader, and coach for agile teams.