Many software development projects are moving rapidly to an Agile development approach which has dramatically impacted the role of a project manager in an Agile environment. Agile also has a significant impact on the role of a Business Analyst. In this article, we will explore “What is an Agile Business Analyst?” and “How is the role different?”.
Traditional Business Analyst Role
The traditional role of a Business Analyst is defined as follows:
“The business analyst’s primary objective is helping businesses implement technology solutions in a cost-effective way by determining the requirements of a project or program, and communicating them clearly to stakeholders, facilitators and partners.” Business Analyst Job Description, Villanova Univ.
That’s the predominant role that has been played by Business Analysts for many years. In some cases, it has boiled down to simply talking to users about what their needs are and writing requirements documents and it has become a very documentation-intensive role. However, the real value-added that a Business Analyst should provide is in helping to define innovative solutions to business problems and not just simply creating requirements documents. In a traditional plan-driven environment, documentation often takes on a life of its own and we lose sight of the fact that the goal is to create business value and documentation is only a by-product.
What Are the Skills Needed by a Business Analyst?
It’s useful to step back and look at the skills that a good Business Analyst needs to really provide value-added beyond simply writing requirements documents. A Business Analyst has to have an understanding of:
- The Business Domain that they work in (finance, healthcare, manufacturing, or whatever else it might be). That means that the BA understands how that business operates, what the major business processes are, the metrics that are important to the business, and how to improve the processes from a business perspective
- Process Improvement Tools and Techniques – They need to understand how to use process improvement tools and techniques such as Six Sigma and others to analyze an existing business process and identify and define opportunities for improvement
- An IT Solutions perspective – they need to know how to translate that understanding of the business process improvement needs into IT solution requirements to create effective and innovative business solutions.
- A Project Process Understanding – Finally, they need to understand how an overall project development process works and how their role fits into that process so that they can work most effectively as a member of a development team.
These fundamental skills have not changed over the years and a good Business Analyst is strong in all of these areas; however, in some cases the role of a BA has degenerated into simply writing requirements documents.
What Is Wrong With the Traditional Business Analyst Role?
The problems with the Traditional Business Analyst role are essentially the same as a Traditional Project Management role.
- Level of Uncertainty – In today’s environment, there is a much higher level of uncertainty associated with defining software solutions. The traditional approach of documenting detailed requirements for projects prior to the start of the project just doesn’t work well with high levels of uncertainty. You would likely wind up wasting a lot of time trying to define detailed requirements upfront prior to the start of the project based on speculation and those requirements might then go through an enormous amount of change as the project is in progress.
- Emphasis on Creativity and Innovation – In the past, the primary emphasis in many projects has been on planning and control to achieve predictability of project costs and schedules. Competitive pressures today have created a need to put more emphasis on creativity and innovation to maximize the business value of the solution. An over-emphasis on planning and control can destroy creativity and innovation. Can you imagine trying to develop the next generation of a very innovative product like a new iPhone using a traditional, plan-driven approach based on developing detailed requirements for the product upfront?
How Do Agile Requirements Work?
To understand the role of a Business Analyst in an Agile environment, we first need to understand how an Agile requirements process works. There are a lot of misconceptions about Agile – some people may think that there are no documented requirements and the project is started by the developers writing code. That is not the case. The approach for developing requirements in an Agile project should be directly related to the level of uncertainty in the project:
- In a project with a high level of uncertainty, it would be foolish to try to develop detailed requirements prior to the start of the project and the requirements might be limited to an overall vision and high-level requirements that the project must meet. More detailed requirements would be further elaborated as the project is in progress based on direct feedback and inputs from the users.
- If there is a lower level of uncertainty, the project might go further towards developing more defined requirements particularly if there is a need for some level of predictability of the project costs and schedule. However, an Agile environment would still emphasize some level of flexibility and adaptivity to maximize the business value of the solution as the project is in progress.
There are several key differences in an Agile approach:
- Less Emphasis on Documentation – Agile requirements are considerably simplified and are typically written in terms of “user stories”. A “user story” is a brief and very succinct definition of a business need without much detail about how it will be implemented, A “user story” is considered to be a “placeholder for conversation” and it is understood that further definition of how it will be implemented will be determined based on direct, face-to-face communications with the users as the user stories are being implemented.
- Changes Are Encouraged – An Agile approach is designed around flexibility and adaptivity to maximize the value of the solution. For that reason, changes to requirements as the project is in progress are encouraged.
- Direct Communication – There is a lot more direct communication between the business users and the project team. First, there is a Product Owner who represents the business who directly participates in the project to provide overall business direction and priorities. Second, the developers on the project team are expected to communicate directly with the business users to further elaborate and define requirements.
In this kind of environment, I think it should be obvious that the role of a Business Analyst should be more than just a “middle-man” to talk to the users and document requirements. That would inhibit direct communications with the project team and probably also limit the flexibility and adaptivity that is so important to an Agile approach.
What is an Agile Business Analyst?
The role of a Business Analyst in an Agile environment is not well-defined just as there is no defined role for a Project Manager at a team-level in an Agile environment. On small, simple Agile projects there may not be a need for either of these two roles but that is frequently not the case on large, complex enterprise-level projects.
The role of a BA is often neglected – it is assumed that the Product Owner plays that role but it can be difficult for a Product Owner to perform that role without some assistance on very large complex projects. I recently had to create a job description for hiring a BA on an agile project – here’s what I came up with as the primary skills needed:
- Analyzing a broadly-defined area and using functional decomposition to define high-level epics and stories to create a well-organized, value-driven framework to provide the required business value in the Product Backlog. If the stories and epics follow a logical functional hierarchy it provides a mechanism for better understanding the relationship of the stories and epics to each other and for satisfying overall business goals.
- Writing individual stories that are very clear and concise and are easy to understand and implement by the development team.Writing effective user stories is a skill that is often taken for granted. What is often overlooked in good stories is the “why” or the “so that” clause that expresses the business value the story is intended to provide. A good BA can provide that perspective that is difficult for a developer to provide.
- Identifying related user stories and epics, grouping them into themes as necessary and documenting the interrelationship and associated business process flows as necessary.The interrelationship of user stories and epics should be well-understood and the implementation of stories across different functional areas may require some planning and coordination so that they are consistently implemented. This overall framework can provide a mechanism for easily identifying any inconsistencies and/or missing functionality.
- On large projects, there may be a need to integrate the needs of related projects as well as the needs of a number of different stakeholders to produce an overall solution.
The key point is that if a Business Analyst is involved at all in an Agile project, he/she should add value in some way and should not be just an intermediary between the development team and the business users and stakeholders.