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) Requirements are documented in Use Cases, Business Requirements, Functional Traditional BA (Waterfall) Rules. requirements, UI Specifications, Business Requirements are documented in Use Cases,
Agile BA Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases. Agile BA Requirements are documented in Epics, User Business Requirements, Functional requirements, Stories and optionally Business (or Essential) Use Focuses on understanding the problem and being UI Specifications, Business Rules. cases. Focuses on completeness of requirement and the domain expert so that s/he can answer spends time in ensuring the requirement is questions from the development Focuses on understanding the problem and being team swiftly and Focuses completeness of requirement and unambiguous and hasonall the details. the domain expert so that s/he can answer decisively. spends time in ensuring the requirement is questions from the development team swiftly and unambiguous and has all the details. decisively. Focuses on ensuring the requirements meet the Focuses on getting a ‘sign off’ on the Focuses on ensuring the requirements theif it requires currentbusiness needs, meet even requirements. Focuses on getting a ‘sign off’ on the requirements. currentbusiness needs, even if it requires updating updating them. them. is a wall between the BA/Business and Agile BA (Often called as Product is part of Owner) is part Often there is a Often wallthere between the BA/Business Agile BA (Often calledOwner) as Product the Development team. the team. and the Development team. of the team. Has to remain in the problem domain, leaving the Tends to dictate solutions. development team ‘space’ explore different domain, leaving the Has to remain intothe problem solutions. Tends to dictateLong solutions. development team ‘space’ to explore different turnaround. Quick turnaround. solutions. Focus on what the requirements document said. In Focus on the functionality of the developed other words, output (Artifact) is a well written software. In other words, output (Artifact) is the Long turnaround. Quick turnaround. thorough requirements document. software that meets thebusiness needs. Focus on what the requirements document said. Focus on the functionality of the developed In other words, output (Artifact) is a well written software. In other words, output (Artifact) is the thorough requirements document. 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.