Business Analysis in an Agile Environment

As it is used by practitioners, business analysis can be defined as a method that enables organizations to make progressive scope enhancements and bring innovation. The purpose of business analysis is to manage change, which is meant to improve the scope clarity of business proposals. During the past decade, business analysis evolved significantly under the pressure created by a complex and ever-changing business environment. The method allows practitioners to simplify, clarify, and standardize business processes or situations that are either complex or not well defined. However, the practice of business analysis is not always very straightforward. In fact, it has its complications, particularly when organizations have no clear vision regarding requirements or when the requirements themselves are contradictory.

In most real-world scenarios, business analysis can be difficult to run because it is not an exact science but rather a heuristic method that relies on the experience and understanding of the practitioner. Moreover, the analysis must be adapted to various scenarios, some of which may be unique and completely new. Analysis can be interpreted and implemented in numerous manners. Some of these manners are equally correct and applicable to a certain situation, while others may not be as good and, sometimes, completely inappropriate. The bottom line is that each situation must be evaluated individually because it is unique; tailored solutions must be found for each scenario. Very much like car engines, business works smoothly when the constituent wheels, gears, and cogs form a functional whole. For this reason, a business analyst must have a proper understanding of all consequences and take into consideration the chain of effects running across the vertical and horizontal structures of the organization. A proper understanding of the effect enables the business analyst to ensure that all stakeholders are well served and that their needs are fulfilled.

Sequential Development is the traditional approach that allows the business analyst to perform business analysis during the initial phases of a business process. The novelty brought by Agile was that it challenged practitioners to perform business analysis throughout the entire development process. This is a fundamental difference between Agile and Sequential Development because Agile recommends the continual re-evaluation of the initial business analysis. The present article will discuss business analysis in Agile by focusing on Scrum implementation.

In the IIBA Agile Extension to the BABOK manual, we find the following remark: “The techniques of business analysis do not change dramatically in the agile environment […] The techniques utilized in agile approaches do not represent a major shift for business analysts. They continue to utilize many of the tools and techniques defined in A Guide to the Business Analysis Body of Knowledge^® (BABOK^® Guide).”

Notably, the Scrum methodology works in parallel with analysis and development. This happens as a consequence of the principle of collaboration, which is central to the Agile philosophy. In Agile, the deliverables must be produced in a collaborative manner. Scrum teams are cross-functional and multidisciplinary, a model that enables and encourages a collaborative environment optimal for knowledge sharing during the stages of development and parallel to the production process. In the Agile framework, we can identify three main components defining business analysis: (1) analysis, (2) artefacts, and (3) the role of the business analyst. We will detail them next.

The concepts behind analysis do not vary with the process or framework in use. This means that analysis is always a constant, with its component parts remaining the same. For this reason, it is easy to generalize the concepts of analysis to many different business processes. However, we should keep in mind that the output of the analysis process is usually presented in different formats depending on the specific circumstances of a given situation. This variation is closely related to the flexibility associated with the Agile framework.

In the Agile framework, project teams have the ability and freedom to simultaneously pass through the development stages and continue to formulate and document business requirements at the same time. This is where the infamous “analysis paralysis” typically occurs. For this reason, paralysis is less likely to affect Agile teams progressing through the project timeline. In fact, in Agile, they are allowed to start development before the planning stage is considered completed.

In this framework, the product backlog is the first step of the analysis process. The activity taking place under this name is the identification of (1) features, (2) components, and (3) functions. During this phase, the analysis must focus on translating the abstract notion of “product” into precise features, components, and functions.

In early analysis stages, Agile analysts work with a conceptual “product” in a raw form and run it through what we can virtually call a decryption process. At the end of the decryption, the “product” is fragmented into clear and comprehensible features and business solutions. Creating a business solution from an initial abstraction is a key step in business analysis. The next step is to work with the product in its new decrypted state in an open development process, where adaptive execution and iterations facilitate “agile” development.

Subsequent Sprint backlogs rely on the existence of the initial product backlog. The analysis of requirements starts at the same time as the Sprint planning and execution. At this step, the Scrum process uses “user stories” to document and communicate user requirements. Establishing a user story is another aspect of the requirement analysis process, but its effectiveness depends on the content of the user story and the aspects that are covered by it. To make a precise statement, the user story’ is only effective if it is not limited to a straightforward narrative of the business scenario. Instead, the story must analyse rather than describe the scenario and its outcomes. Simple description is not enough; the user story must focus on the consequences and utility of a feature—this is where its value comes from.

Collaborative containment. The open and collaborative Agile environment adds value by enabling requirements to be captured faster while keeping end users involved. It is an intensive exercise requiring the participation of stakeholders. A potential pitfall at this stage is to allow requirements to get out of control. Since requirements are elicited and analysed at every step for the purpose of creating improved iterations, the scope of the iteration must be well controlled.

Information and knowledge are freely exchanged between team members. Thus, when analysis must develop a given input received by the development team in charge of the iteration, the members of the team respond reactively. At this point, designated project team members are assigned to specific tasks.

Fast turnaround. The fluid nature of analysis and its modular, well-defined-in-time character compel it to follow a fast turnaround timeline. Traditional methodologies limit analysis to the design and development phases. Agile brings novelty by asking the teams to parallelize production. Thus, analysis must be performed faster so that design and development receive a timely input, which facilitates the simultaneity of multiple activities.

Agile is meant to break away from the traditional rigidness of the phased approach, which is why it recommends collaboration rather than a focus on documenting the project. Instead of being rigid, deliverables are rather deduced throughout the entire development process in Agile. User stories are used in Scrum to document and share requirements; however, their descriptive nature only provides a high-level image of the information captured in the process. For this reason, IIBA recommends “complementing user stories with other Artefacts.” This enables an analytical interpretation and allows for a complex business analysis to crystallize into artefacts.

The role of the business analyst in Agile is best suited as part of the responsibilities of the product owner. However, it is worth remembering that the Agile Manifesto Principles speak of “flexible roles and equality.” Flexibility in delivery and design are among the core principles of Agile. Naturally, this situation cannot be attained while maintaining a cast-in-stone, rigid hierarchy. The Agile framework suggests the idea that classic boss–subordinate relationships within the project team hinder feedback, performance, and the free flow of creativity. Consequently, structural changes crystallized in cross-functional teams, unbounded by classic subordination relations, result in more fruitful collaborations. In this situation, clear roles dominate the scene, and team members are empowered and encouraged to work toward a common goal. Well-integrated and structurally functional teams work within a dynamic framework to create a background capable of producing results through iterative interactions. Rigid structures based on hierarchical leverage are abandoned here. This is an essential step in the direction of team members having equal contributions and everyone expressing their opinions. Since everyone has the chance to speak, all their experience and knowledge are used. While equality dominates, the chances to see divergent standpoints increase as a downside. In response to this potentially adversative environment, everyone must exercise better reasoning, performance, and analysis. With business analysis, the team member in charge must wear multiple hats. 

As a business analyst, he or she must be versatile enough to be able to juggle the multiple roles assigned to everyone in the Agile environment. We should not be surprised if we find the soul of a business analyst in every team member, disguised underneath a formal functional appearance bestowed upon him or her. Critical thinking, great communication skills, and an aptitude for analysis are the most important soft skills necessary to thrive as a BA.

Interestingly, Agile does not name business analysis as a separate element of the Agile methodology. What Agile does instead is recommend a free-flowing approach that allows for the adaptation of roles and functions by focusing on the necessary deliverables. In fact, the expected deliverable defines the role. This philosophy is intended to promote free interaction and versatility of roles. By encouraging a flexible, holistic environment, the Agile philosophy creates a background for collaboration. In this context, business analysis is inevitably emphasized as the heartbeat of the Agile framework.

Author: Adam Alami, Sr. Business Analyst

Adam Alami is a seasoned IT consultant with over 18 years’ experience. Business Analysis and Project Management is his passion. His experience revolved around major business transformation projects. He is a versatile IT professional. He accumulated a wealth of cross industry experience with Tier 1 businesses in major projects in the areas of Enterprise Transformation, Integration, Migration, and Systems Modernization.

Adam has a passion for research. His research interests are IT Offshoring, Global Project Managements, Banking Technology, Business Analysis, Information Technology and Culture, Enterprise Innovation and Business Solutions.