The Role of a BA in

Agile Environment

(Professional Business Analyst Training

organisation)

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.

•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 currentbusiness 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 thebusiness needs.

   

Traditional BA (Waterfall) Agile BARequirements 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 currentbusiness 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 thebusiness 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.