I am constantly getting these questions from business analysts:

What role does a BA play in an agile project?

What kind of tasks/documents the BA is responsible for in an agile project?

Where does a BA fit in a Scrum project, where you only have three roles, product owner, ScrumMaster, and team?

Before I give my answer, I need to provide a disclaimer: because I work mostly with large, complex software projects, for which hybrid approaches are typically the best alternative, I have never worked in a “pure agile” environment. As a matter of fact, I was hired a couple of times to help transform a project from pure agile to a hybrid model that better reflected project profile. Read this article with this frame in mind.

My guess is that BAs asking these questions are in one of two categories:

• They have a current BA role in an organization or team that is switching to agile development.
• They are applying to BA jobs that mention agile as the development approach of choice, and only have experience with traditional software development methods.

In the first case, the BA will be wondering what will happen to his/her role–is there a risk the position will be eliminated in the new environment? After all, it’s rare to see an agilist even mention the business analyst role. In the second scenario, the BA may be concerned that their experience in a non-agile world may not be relevant to the position, specially since  in agile projects there is no lengthy requirements analysis phase, and documentation is supposed to be very lightweight.

In both cases, BAs with great communication and analytical skills will always be on demand. In the first scenario, the BA may need to proactively demonstrate how his/her work can add value to the company’s software initiatives; in the second one, the company already knows that a talented analyst will be an asset to their projects, if they are advertising a position with this title.

Regarding documentation, companies learn, sooner or later, that good documentation is crucial for the success of many software projects. In this article for Bridging the Gap I describe multiple situations in which high-quality documentation (written or in other formats, such as video recordings) may be indispensable for meeting business needs. Talented business analysts (regardless of their title) can help agile teams in all aspects of communication, from selecting the documentation methods and formats that are most appropriate for the project, to producing relevant artifacts. More importantly, they can ensure that the right deliverables are ready at the points of the project when they are most needed, and later when the software product has been handed off to another team for maintenance.

Besides producing useful, risk-reducing documentation, business analysts (which should not be writing code in order to focus on, well, analysis) can add value to agile project in many ways, including:

• Helping stakeholders assess their needs and make timely and well-founded decisions about features, priorities, issues, acceptance criteria.
• Identifying epics, user stories, and test conditions in facilitated sessions.
• Performing the analytical work necessary to achieve in-depth understanding of the problem and solution domains.
• Ensuring that there is enough comprehension of the “big picture” as stakeholders provide feedback for implemented pieces of functionality, to minimize the risks of bounded rationality.
• Helping integrate the requirements of different segments of stakeholders through negotiation.

Business analysts who start to work on agile projects will undoubtedly have to adapt to different practices, which include more intensive use of face-to-face communication to transfer ideas from business stakeholders to the development team, different techniques (such as user stories) to define high-level requirements, iterative requirements analysis throughout the project, and so on.

Agile projects come in all shapes and forms, and the techniques a BA will use in agile projects may vary significantly. However, requirements activities don’t go away in agile software development: requirements elicitation, analysis, negotiation, documentation, validation, are activities that still have to be performed during each of the several short development cycles of an agile project (even if there is no clear boundary between all these activities). In my experience, smart agile teams are extremely aware of the difference that a talented BA can make in their projects to mitigate a variety of risks — from inadequate user-developer interaction and neglected non-functional requirements to scheduling flaws.

As Laura Brandenburg wrote in Professional Development for Business Analysts,

Always stay focused on the value you provide and finding ways to increase it. There is no better career booster than excelent performance.

Read also: Why Skilled Business Analysts Will Not Go Away in an Agile World