Many software development projects are moving rapidly to an Agile development approach:
- That 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?”, “How is the role different?”, and “What training is needed?”.
Overview
What is the role of an Agile Business Analyst? The influence of Agile is having a significant impact on the role of Business Analysts. In a traditional, plan-driven environment; the role of a Business analyst is very documentation-focused.
- A key role has been working with users to understand and document requirements.
- In an Agile environment, that role is no longer as important and a Business Analyst needs to provide a higher level of value-added.
So, what role should a Business Analyst play in an Agile environment?
- The role of a Business Analyst should be more than just an intermediary to talk to the users and document requirements
- That role would inhibit direct communications with the project team. It would probably also limit the flexibility and adaptivity that is so important to an Agile approach
In an Agile environment,
- It might be assumed that the Product Owner plays the role that might normally be played by a Business Analyst. However, the Product Owner responsibility goes well beyond the role of a Business Analyst, and
- It can be very difficult for a Product Owner to perform that role without some assistance on very large, complex projects
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.
- He/she should not be just an intermediary between the development team and the business users and stakeholders
- The role should not be limited to creating requirements documents
To better understand this transition, we need to first understand the traditional Business Analyst role.
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, the role has primarily focused on simply talking to users about their needs and writing requirements documents.
- That has been 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
- It should not be limited to just simply creating requirements documents.
In a traditional plan-driven environment, documentation often takes on a life of its own. In that environment,
- It is easy to lose sight of the fact that the goal is to create business value and
- Documentation is only a by-product
How is this role different in an Agile environment?
What Are the Skills Needed by an Agile Business Analyst?
In an Agile environment a Business Analyst needs to provide value beyond simply writing requirements documents. The Business Analyst has to have an understanding of:
| Knowlege Area | Requirement |
|---|---|
| Business Domain Knowledge | In-depth knowledge of the Business Domain that they work in (finance, healthcare, manufacturing, or whatever else it might be). That means that the BA understands:
|
| Process Improvement Tools and Techniques | Understand how to:
|
| IT Solutions Perspective | Know how to translate understanding of the business process improvement needs into IT solution requirements to create effective and innovative business solutions |
| Project Process Understanding | Need to understand:
|
These fundamental skills have not changed over the years. A good Business Analyst should be strong in all of these areas.
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
Today’s environment typically has a much higher level of uncertainty associated with defining software solutions. The traditional approach of documenting detailed requirements prior to the start of projects just doesn’t work well with high levels of uncertainty:
- A lot of time might be wasted trying to define detailed requirements prior to the start of the project
- Many of those requirements might be based on speculation and assumptions, and
- Those requirements might then go through an enormous amount of change as the project is in progress.
Emphasis on Creativity and Innovation
The emphasis in many projects is shifting:
- In the past, the primary emphasis in many projects has been on planning and control
- A key goal was 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?
- It would be impossible to do that 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
- 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
High Levels of Uncertainty
In a project with a high level of uncertainty, it might be foolish to try to develop detailed requirements prior to the start of the project:
- In that environment, 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. That elaboration would be based heavily on direct feedback and inputs from the users
Lower Level of Uncertainty
If there is a lower level of uncertainty, the project might go further towards developing more defined requirements.
- That might be particularly true 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
Key Differences in Agile Business Analyst Role
There are several key differences in an Agile approach:
1. 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. It does not provide any detail about how it will be implemented,
- A “user story” is considered to be a “placeholder for conversation”. Further definition of how it will be implemented will be determined based on direct, face-to-face communications with the users. That will take place as the user stories are being implemented.
2. 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.
3. 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. The Product Owner 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. That is essential to further elaborate and define requirements as the project is in progress
In this kind of environment,
- The role of a Business Analyst should be more than just an intermediary to talk to the users and document requirements
- That role would inhibit direct communications with the project team. It would probably also limit the flexibility and adaptivity that is so important to an Agile approach
What Exactly is an Agile Business Analyst?
What is an Agile Business Analyst?
- The role of a Business Analyst in an Agile environment is not well-defined
- On small, simple Agile projects there may not be a need for a Business Analyst role
- That is frequently not the case on large, complex enterprise-level projects
In an Agile environment,
- It might be assumed that the Product Owner plays the role that might normally be played by a Business Analyst. However, the Product Owner responsibility goes well beyond the role of a Business Analyst, and
- It can be very difficult for a Product Owner to perform that role without some assistance on very large, complex projects
A More Value-Added Business Analyst Role
The value-added provided by a Business Analyst in an Agile environment needs to go beyond simply writing requirements documents. Here are some potential ways that a BA can provide a higher level of value:
1. Process Improvement
Many times, simply automating a process “as-is” does not provide a sufficient level of value.
- Rather than simply documenting a process “as-is”,
- A Business Analyst can provide a much higher level of value by finding innovative ways to improve an existing process to make it more efficient or more effective
2. Analyzing a Broadly-Defined Area
In large, complex projects:
- Using functional decomposition can be essential to create a well-organized, value-driven framework
- That helps to align the Product Backlog with the required business value
- It also makes it easier to understanding the relationship of the stories and epics to each other and for satisfying overall business goals
3. Writing Individual Stories
A Business Analyst can provide value by writing user stories that are very clear and concise and easy-to-understand and implement by the development team.
Writing effective user stories is a skill that is often taken for granted.
- In good stories the “why” or the “so that” clause that expresses the business value the story is intended to provide is important
- A good BA can provide that perspective that is difficult for a developer to provide.
4. Identifying Related User Stories and Epics
In a large complex project, there is value in grouping stories into themes and epics as necessary. That can be essential to understand the interrelationship and associated business process flows.
- 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.
5. Integration With Related Projects
On large projects, there may also be a need to:
- Integrate the needs of related projects as well as
- Integrate the needs of a number of different stakeholders to produce an overall solution.
Overall Summary
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.
- He/she should not be just an intermediary between the development team and the business users and stakeholders
- The role should not be limited to creating requirements documents
Related Articles
Check out the following related articles on “Agile Business Management”:
- What Happened to Southwest Airlines?
- Is Elon Musk a Good Agile Manager?
- New Agile Training for Business Managers
- What Is the Relationship of Design Thinking and Agile?
- What Are the Critical Skills of a Scrum Product Owner in Agile?
- How Do You Choose the Right Agile Approach for Your Business?
- What’s Different About Agile Metrics?
- What is Systems Thinking and Why is it Important?
- Agile Contracts – How Do They Work?
- Agile Business Strategy – Making Agile Work for Your Business
Additional Resources
Resources for Agile Project Management Online Training.
“Functional Decomposition” is a standard business analysis technique that has been around for a long time. It involves a top-down approach of starting with high-level business objectives and progressively decomposing those high-level business objectives into lower-level requirements that are needed to fulfill those objectives (in Agile terminology that would typically be epics and stories).
The problem with many Agile implementations is that it is many times perceived as an “all-or-nothing” proposition (either you’re totally Waterfall or totally Agile) and you have to throw out anything you’ve ever learned about plan-driven approaches to become Agile. That might work for small, simple Agile projects, but it doesn’t work well at all when you attempt to scale Agile to large, complex enterprise-level initiatives. That kind of project typically requires managing the effort at multiple levels (not just the development process) and requires mixing-and-matching plan-driven principles and practices with Agile principles and practices in the right proportions to fit the situation. That is not an easy thing to do – it requires more skill to do that than it does to force-fit a business or a project to some kind of canned methodology, but it can be done. That is the essence of what my new book is all about.
I don’t have a job description for a BA in an Agile project, but I have written a blog post on that subject:
http://managedagile.com/2013/04/20/the-role-of-a-business-analyst-in-an-agile-project/
Hi
very informative article i will do this in future – https://www.edupristine.com/blog/business-analyst-jd-duties-salary
This is the best description regarding the agile BA role I’ve seen to date. Thank you.
Great explanation on the BA agile connection. i still believe traditional BA requirement gathering is very important even in agile methodology. taking a clue from the iPhone X instance. Do you think a-first-of-its-kind solution (a typical version one) program should not be well documented? i believe the first version of iPhone documentation has prepared the scalability and efficiency of the now iPhone X. Improvement and features are typically easier to apply on a grounded, prepared foundation.
My thought though
A fundamental principle that I have emphasized throughout my training on Agile Project Management, I have emphasized that there is not a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think. And, you have to fit the methodology to the nature of the project rather than force-fitting all projects to some predefined methodology. Another rule that I advocate is that you shouldn’t create documentation for the sake of creating documentation. Any documentation that is created should provide value to someone in some way.
So, I would not make a general statement as you have made that “BA requirement gathering is very important even in agile methodology”; however, there could be some situations where that role does provide value.