The Business Analyst Role in the Agile World

Facilitating risk discovery and assisting the team in retaining focus on effective risk mitigation is central to the analyst’s role on an agile team.  Iterative development processes provide opportunities for increased efficiencies in the work of business analysis. In non-agile projects (i.e. waterfall projects), requirements are developed in their entirety prior to the development phase. As risk elements are uncovered and business needs evolve, certain requirements may change or be eliminated outright; making the work effort put into those requirements wasted. By providing just-in-time requirements via agile development, there is less rework of requirements because only the requirements required for the current release are defined in detail and developed.

The techniques of business analysis do not change dramatically in the agile environment. However, the timing and how they are used do change. Artifacts such as personas, data models, story maps, and business rules continue to be employed, but are kept as lightweight as possible. Low-fidelity artifacts, such as diagrams, maps, and lists, provide more value to an agile project than long, textual requirement descriptions or specifications. Low-fidelity artifacts are developed for the sole purpose of building the software for a specific iteration and only need to be intelligible to the team during the course of the iteration. Long-lived artifacts, on the other hand, are intended to be utilized beyond the scope of development. Long-lived artifacts may include the business case, charter, and documentation that is used to communicate what the software does and why it does it.

Agile offers the opportunity for the business analysis to benefit from the frequent feedback provided by the business. By reviewing the results of successive iterations with the business stakeholders, analysts have the opportunity to

• refine the product’s requirements to ensure they maintain cohesion with the business needs for the product
• identify and mitigate risk early in the project

 

There are a variety of ways a business analyst can be engaged on an Agile project:

• In more complex environments the analyst might be the facilitator, bringing divergent business stakeholders together and helping them speak with a single voice so the project team are not confused by contradictory and conflicting perspectives.
• The analyst might act as the product owner/customer representative where they are empowered by the business to make decisions on product features and priority.
• The analyst could act as a surrogate product owner, in situations where the business product owner not available.
• The analyst might act as the second in command to a business product owner with limited availability.
• An analyst could take the role of business coach in an environment where the business product owner is competent and committed, but has limited IT project experience and the rest of the development team are lacking in domain knowledge.

Irrespective of job titles, business analysis is about ensuring the project is able to deliver the maximum value for customers and adapting to the evolving business needs.