The Role of a BA in Agile Environment

How the role of the BA would change in an agile environment?

Software development teams transitioning form a Waterfall methodology to an Agile methodology often have difficulty in clearly defining roles and responsibilities of the team members. This is especially true for the role of BA, as agile teams include a business owner who plays a more involved role than in a Waterfall process.

The Role of a BA in Agile Environment

The Role of a BA in Agile Environment

Agile is a software development methodology that depends on establishing a direct link between developers and users. It is based on the premise that requirements will change and as such, there’s no need to invest in producing “time-consuming” or “lengthy” requirements specification documents. An initial requirements envisioning is done to clarify the project scope; an estimate of effort required to deliver the software is produced and requirements are elaborated as needed based on constant prioritization.

The following table tries to compare how the role of Business Analyst changes in an agile environment.

Traditional BA (Waterfall)

Agile BA

Requirements are documented in Use Cases, Business Requirements, Functional requirements, UI Specifications, Business Rules.

Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.

Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.

Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.

Focuses on getting a ‘sign off’ on the requirements.

Focuses on ensuring the requirements meet the current business needs, even if it requires updating them.

Often there is a wall between the BA/Business and the Development team.

Agile BA (Often called as Product Owner) is part of the team.

Tends to dictate solutions.

Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.

Long turnaround.

Quick turnaround.

Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.

Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets the business needs.


How can the traditional BA blend in an agile environment? Here are the challenges:

  • Agile requires that the BA produce requirements faster by analyzing through “observation”  or “trial-and-error” instead of attempting to find out all the facts before development begins
  • Lengthy business requirement documents are not required; the level of detail is different. Less has become more

In most of the cases of an  Agile environments however, requirements specification documents are not priority. Users and developers are expected to sit in the same room and agree on what will be developed, with little emphasis on the requirements specification document, thus threatening the role of the middleman – the Business Analyst.


Leave a reply

Your email address will not be published. Required fields are marked *


©2016  All Rights Reserved Last Mile Systems

Log in with your credentials

Forgot your details?