How BA is handled in waterfall and agile?

The two approaches that have been considered in the first section below are the Waterfall and Agile. Because both Waterfall and Agile approaches can be done incrementally, an Incremental process, as a separate approach, is not discussed.

1. When the business analysis work occurs                   

When the business analysis work occurs, it varies by the approach that has been chosen. Specifically:

Waterfall – With the Waterfall process, most business analysis work occurs at the beginning of the project or during one specific project phase. The exact name of the phase varies by the specific methodology, but the main focus of the phase includes activities like eliciting, analyzing, and communicating the requirements, as well as reporting on the status of the business analysis activities work for the project. In general, there is more formality with the Waterfall approach.

Agile – On some Agile projects, enough of the business analysis activities occur in an initial project phase to produce a list of requirements, which are analyzed and developed iteratively. On others, there is less work completed in the beginning of the project, and business analysis activities can occur iteratively throughout the project.

2. Formality and level of detail of the business analysis work

Waterfall – This approach typically calls for a significant amount of detail when completing the business analysis work. Commonly there is a formal requirements specification that is produced at the end of this project phase, with detailed information about the requirements. The specific content and format of the requirements document can vary, depending on the organizational methodologies and/or processes, and templates.

Agile – This approach favor focusing on a working solution over documenting that solution. Requirements documentation is often limited to a prioritized requirements list. Additional documentation may be created at the discretion of the team. Note that the relative lack of requirements documentation does not equate to a lack of understanding regarding the requirements among the team, since the understanding of the requirements is demonstrated through mechanisms other than a formal, written document.

3. Requirements prioritization

Waterfall – Requirements are often prioritized at the end of the project phase. Although a broad-brush prioritization using general categories, such as high, medium, low are sometimes applied as requirements are identified, determining which are in or out of scope usually occurs at the end of the phase. In addition, prioritization tends to be completed with more formality.

Agile – The requirements on the requirements list are prioritized, estimated at a high level, and the most important requirements from a technical and business perspective are selected for the first/next increment. Once the requirements have been assigned to the increment, those specific requirements for the increment are drilled down to a lower level of detail. This general process repeats each time one increment ends and another begins. The distribution of business analysis work load is spread more or less evenly throughout the project.

4. How change is handled?

Changes to requirements may occur at any time during the project. The process for handling changes is different for each approach.

Waterfall – Each change is often handled as a ‘mini project,’ complete with requirements gathering, estimates, design, etc. Changed requirements often mean changes to the project baselines and are usually incorporated into the overall project management plan.

Many organizations have a formal process which includes a request for change, a change log that tracks the changes that have been received, and an analysis of the impact of the change not only to the project, but also to other business and automated systems.

Agile – The Agile approach work on the premise that it is difficult to identify all requirements at the beginning of a project. Agile approaches build change into their core processes. Change is documented by maintaining and comparing the requirements lists at the end of each increment. New and removed requirements are noted, as are changes in priority for each requirement, the estimates for each requirement, and the assignment of requirements to increments.

5. Communication with stakeholders

Communications may be written or verbal, formal or informal.

Waterfall – The communication between stakeholders and the project team tends to be more formal. Much of the communication of the actual requirements is in writing, and often uses predefined forms requiring signature approvals.

Agile – The projects tend to focus more on frequency of communication than on formal documentation. Official documentation is often in writing, but informal communication takes precedence over more formal written communication. Standard good business practices i.e. meeting agenda, meeting minutes remain in force.

To know more about the final considerations for business analytics process, please read the next blog