What is Agile Business Analysis?

Business Analysis

Business Analysis is the discipline of identifying business needs and determining solutions to business problems or opportunities. Solutions include Software, Infrastructure, Process improvement, Organizational change, Policy development, etc. Solutions must deliver value to stakeholders. Business Analysis is thus a disciplined approach for introducing and managing change in an organization by articulating the need for the change and facilitating its implementation. In short, Business analysis helps organizations do business better.

Business Analysis in traditionally managed / Waterfall projects

Business analysis in traditionally managed Software projects starts with the “requirements gathering” phase. These requirements are then analysed against the context of needs, organizational goals and objectives, solution assessment and validation. The function of Business Analysis tends to be more heavily employed in the early stages of the Software Development lifecycle as shown below. Some organizations continue Business Analysis in the testing phase as a validation of the solution against the requirements / needs.

The traditional / sequential or waterfall approach to Software Development

The key roles of a Business Analyst

The key responsibilities of a Business Analyst in traditional or Waterfall type projects include;

• Extracting requirements from users and customers

• Simplifying requirements (Breaking down large and complex requirements to smaller and manageable ones)

• Verifying requirements

• Constraining or freezing requirements to manage change

• Translating requirements to technical speak

• Organizing requirements into categories

• Managing requirements through the process of Software development

• Maintaining requirements (and the solution) after deployment

Business Analysis in the Agile (Scrum) Context

In the Scrum approach to Software Development, there is no title called “Business Analyst”. There are only three titles in Scrum: Scrum Master, Product Owner and Developer. This does not mean that there is no place for Business Analysis in Scrum. As we know, Scrum emphasis small cross-functional and self-organizing teams of no more than 11 members. The Scrum team is expected to possess all the skills as necessary to produce a product increment. This includes the skill of Business Analysis, especially in how requirements are handled in Scrum.

It is important to recognize that in Scrum, the team takes collective accountability for all aspects related to software / product development. This includes Requirements, Design, Code, etc. This is intentional and in keeping with the fundamental objectives of close collaboration and effective communication in Agile. This focus on collective accountability contrasts strongly to the traditional / waterfall approach which emphasises distribution of accountabilities among various “roles” or “titles”. As such Business Analysts are “accountable” for getting the requirements right. That is why they pursue “acceptance” or “sign-off” of requirements to handle their accountability.

Another major difference in how requirements are handled in Scrum compared to Waterfall projects has a significant influence on the function of Business Analysis. In Scrum, requirements (also known as Backlog) are constantly prioritized, during the early stages of the project and throughout the sprints as shown in the figure below. Requirements are prioritized based on their “value” to the business. Often, value changes over time because of the dynamics of business. Hence, it is only natural that the priority of requirements also change. Agile teams recognize this and welcome changes to requirements and embrace change unlike Waterfall teams that resist it through “change control” or “change requests” to “freeze requirements”.

The Scrum approach to Software Development

• The Scrum team (as a collective unit) starts with a focus on the Software product being developed in the project (In Scrum a project is visualized as a “product” or “product increment” rather than as phase, activity or function)

• The Product is de-constructed into its backlog (requirements)

• The Backlog is arranged according to how the product can be evolved in terms of its features and in terms of value to business. The objective is to deliver working software as quickly as possible and then add features and functions to it (Progress over perfection)

• Development work is carried out in time-boxed sprint cycles (1-4 weeks). Teams work on the highest priority requirements (a smaller subset of the entire list of requirements) and deliver them completely in that Sprint. After completing one sprint or iteration they immediately start the next one and pick up the set of next higher priority requirements. This way teams aim to deliver working software in a regular, quick and adaptable manner.

Business Analysis skills are continuously used in articulating the product vision, de-constructing the product into requirements (backlog), prioritising them, eliciting the details for requirements as and when needed and managing changes to requirements through reprioritization and scheduling them in sprints. The difference is in the effectiveness of those skills and how those skills are used collectively across team members.

User Stories vs Business Requirements Document

Another significant difference in the function of business analysis in Scrum is in how requirements are defined or written. In keeping with the Agile values that “working software is preferred over comprehensive documentation”, Scrum teams avoid creating large and comprehensive “Business Requirements Documents”. Instead they focus on creating what are called “User Stories” that effectively, succinctly and clearly capture a requirement from the user perspective in just three segments as shown below.

“As a potential borrower for a home loan, I want to use a mobile app that gives me conditional approval for the loan, so that I can confidently bid for a property at the auction”.

The “User Story” has three key parts to it: User or Group of users with the common requirement, an action performed by the user and the Value of that requirement to the User.

A User story is written in plain English, is simple and has the potential to be understood in the same way by the user and the development team with no loss in translation or interpretation. The Scrum team can then build a solution that satisfies this requirement (User story). Obviously, the team may have a few conversations with the user and amongst itself to clarify or expand aspects of the requirement. The overall Product being developed will contain several User stories, some small and others large (called Epics) in development size. When assembled together, all the User stories will define the entire product. Writing good User stories requires strong Business Analysis skills and a very different mindset compared to writing BRD’s.

Tips for developing Agile business analysis skills

• See the whole. Teams need to see the problem / opportunity in the context of the big picture, especially from the value perspective

• Think as a Customer. Teams need to understand value from the customer perspective and determine the smallest unit of deliverable value to the customer and start work on it

• Get real with examples. Rather than rely or use theoretical models, Teams must use real-world examples as much as possible to get the right context.

• Understand what is valuable. Teams must clearly understand the “value part” of the product request and know who derives that value and why that value is important to them

• Analyse to understand what is doable within a Sprint cycle. Teams must know their Sprint capacity and what value can be delivered within that capacity. They should understand how a releasable product would look like and be able to iterate towards it.

Conclusion

Scrum does not have a formal role called “Business Analyst”. However, the skills and functions of “Business Analysis” are extensively used in Scrum. They are used in a very different way in keeping with the values and principles of Agile. This is often a shock to traditional “Business Analysts”. BA’s that adapt to the “Agile Mindset” become valuable Scrum team members and deliver successful projects.