Business Analysis in Agile

Business Analysis in Agile

How does Business Analysis in Agile work? Business analysis is the practice that empowers organizations to progressively innovate and implement ‘change’ to enhance the scope of the business proposition. The practice has evolved considerably over the last decade due to the increased complexity of the business environment. The practice enables organizations to simplify and streamline vague and complex situations. This is a complicated process as the organization might not have a clear picture of the requirements, or conflicting requirements may persist.

In practice, business analysis is not an exact science. ‘Analysis’ is open to varied interpretations and diverse implementation. Every situation is unique and requires an individualized approach. Businesses, akin to engines, perform well when their constituent gears, cogs, and wheels work in unison. A business analyst needs to understand and account for the effect of every action across different levels and convey the need to consider and ensure the welfare of the stakeholders.

In the traditional sequential development process, business analysis is mainly conducted at the initial stages of the process. Agile challenged this method to alternatively embed the function of business analysis all along the development process. This fundamental difference seeks revaluation of business analysis in Agile. This article will attempt to use Scrum implementation of Agile to understand business analysis in Agile.

Business Analysis in Agile

The IIBA Agile Extension to the BABOK claims, “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).”

Analysis and development are done in parallel in the Scrum process. This is based on the ‘collaborative’ principle of Agile, wherein the final product is produced ‘collaboratively’. The Scum team is supposed to be multidisciplinary and cross-functional, which facilitates an environment of knowledge sharing in parallel to the production process. There are three key components that constitute business analysis practice in the Agile framework: (i) Analysis, (ii) Artefacts, (iii) the Business Analyst’s role.


When it comes to analysis, ‘analysis’ is ‘analysis’! Irrespective of the process used, ‘analysis’ and the methods used to ‘analyse’ remain the same. However, there is a slight variation in the format in which the output of the analysis process is presented. This variation is inherent to the Agile framework and its associated methodologies.

The Agile methodology provides the team with the capability to simultaneously proceed through the development process while they continue to gather the business requirements. Hence the usual phenomenon, known as ‘analysis paralysis’, is less likely to hinder the team from progressing until the planning stage is completed.

In Scrum, the analysis process starts by compiling the ‘Product Backlog’. This activity entails identifying the product’s features, components, and functions. The analysis in this stage of the process decodes the concept of the ‘product’ into discreet functions, features, and components.

The early stages analysis in Scrum takes an abstract ‘product’ from its pure, raw conceptual state to a decrypted state. This leads to fragmentation of the ‘product’ into comprehendible functions, features, and business solutions. This untangled state of the product and an open development process facilitates an iterative and adaptive execution throughout the development process.

The ‘Product Backlog’ is the foundation for subsequent ‘Sprints Backlogs’. Requirements analysis in Scrum is initiated with the Sprint planning and execution. ‘User Stories’ are a form of capturing and communicating user requirements in Scrum. The process for establishing the ‘User Story’ is another form of requirements analysis. However, the effectiveness of the analysis process would depend on the content and coverage of the ‘User Story’. It would not be an understatement to assert that a User Story is effective only if it goes beyond a simple narrative of a given business scenario.

In Agile, analysis is not necessarily limited to the role of the business analyst. Analysis is done collaboratively. This enhances the process as the power of the whole team critically thinking together is greater than one individual doing the job. Analysis is nurture through collaboration and the power of the team. The collaborative environment helps to establish trust and information sharing. This creates a fast and dynamic process.

  1. Collaborative containment: The collaborative environment enables for capturing requirements faster with the close involvement and participation of the end users. Due to the iterative nature of requirements elicitation and analysis, it becomes important to contain the scope of the iteration. Knowledge is shared amongst team members, and information is exchanged freely. Thus when analysis is required to unravel a given input to the development of the iteration, team members respond reactively and assign specific tasks to designated team members.
  2. Fast turnaround: Due to its time-boxed and fluid nature, analysis has to adhere to this setting. Traditionally, analysis was a prerequisite to the design and development process. However, Agile advocates parallel production. Hence analysis has to be done faster in order to provide a timely input for design and development in order to mitigate the interdependency amongst multiple activities.


While the phased approach believes in deliverables, Agile recommends collaboration and less focus on documentation and breaks away from the associated rigidity. The process of deducing the deliverables and the nature itself vary in Agile. Scrum uses ‘User Stories’ to document and communicate requirements. The narrative nature of the ‘User Stories’ limits the information captured to a high level. However, IIBA recommends “complementing user stories with other Artefacts.” This furthers the analytical interpretation and fosters business analysis that crystallizes into Artefacts.

The Role of the Business Analyst in Agile

The role best fits within the scope of responsibilities defined for the Product Owner. However, one of Agile Manifesto’s principles is ‘Flexible Roles and Equality’. Agile promotes flexibility in design and delivery. This state cannot be achieved through a rigid structure cast in hierarchy. It is felt that the typical boss–subordinate relationship hampers the free flow of ideas, feedback, and performance.  Herein, cross-functional teams without structural linkages prove to be more collaborative since the roles are clearly defined and each team member undertakes to contribute towards a common objective. This forms an integrated team that operates within a dynamic framework to bring together the resources that yield results through iterative interactions. The hierarchy and rigidity of structure is abolished, which encourages equal contribution and enables everyone to voice their opinions. Thus equality prevails, enhancing incidences of divergent viewpoints. This fosters better reasoning, analysis, and performance. In this dynamic environment, the business analyst has to wear multiple hats. The business analyst has to be very versatile in order to juggle the multiple roles that each member embraces in an Agile environment. It shouldn’t come as a surprise if we find that every team member has the soul of a business analyst hidden underneath the functional facade bestowed upon her or him.  Analytical aptitude, communication, and critical thinking are a few of the soft skills that a business analyst must possess.

Agile does not explicitly identify business analysis as a component of the Agile framework. Instead, it advocates a generic approach to adapt roles and functions through self-proclaimed deliverables. The rationale behind this philosophy is to promote collaboration aimed at fee interaction that enables versatile contribution to foster a flexible and holistic work environment. Business analysis can inevitably be treated as the heartbeat of an Agile framework.

Related Articles:

Degree of Agility: How Much to Agile?

Agile Manifesto

Scrum Defined

Category : Agile
Tags :