One of the many differences between traditional IT projects and agile projects is the role of a Business Analyst. In traditional IT projects, Business Analyst’s role is limited only until the requirements phase. Business Analyst will gather and analyze the requirements, write dangerously lengthy documents (BRDs and FRDs), and pass on these heaps of documents to the development and testing teams. Sometimes the analyst may also write high-level test cases and perform some system testing. Moreover, if there are any changes to the baseline documents, the analyst will come into play again, update the documents and pass the same to the dev team. That is it.
Once the documentation is completed and passed on the dev/testing team, the BA moves on the next project. Either the business owner or the dev team raises the slightest change to the baseline requirement, which in fact is a BA’s job to do proper gap/impact analysis. If we observe carefully, the role of BA in traditional IT projects is more of “it’s not my job” type rather than a proactive one.
Consider an agile project on the other hand. Agile projects do not require massive documentation in advance. Moreover, in agile projects, the business owner might communicate directly with the agile team (developers) and sometimes the agile teams are even co-located, which makes the communication between business owner and agile team easier.
So, there is no role of a Business Analyst in agile projects you say!
If we map traditional BA’s job to agile projects, then the role of a BA is of little value as a Documenter in agile. Since, as compared to traditional software projects, agile does not require massive documentation in advance and rather focuses on face-to-face communication.
Moreover, there are certain dangerous assumptions made by agile teams. You can read these assumptions in my previous article. Apart from these, the most important factor is the unavailability of business users or product managers. Good product managers have very limited time to spend with the development teams, as they are constantly figuring “what” rather than “how”, busy in figuring the product strategy and road-map. Hence, we cannot blame the product managers for limited time.
People are always inclined towards their thoughts, feelings and opinions. And this inclination often tends to introduce bias in their actions and they become quite subjective rather than being objective. So it is quite natural that Business owners/Product Managers get inclined towards certain product features and raise their priorities. This bias might work against the actual business needs.
To address all the above problems, it is imperative for organizations to have a full time Agile Business Analyst in the team. Notice the word “Agile”. Why I tend to focus on the word agile is because the responsibilities of a BA differ drastically in agile and traditional software projects.
Agile BA performs the following activities on a full time basis:
- Gather requirements
- Evaluate whether the software being developed satisfies the business needs
- Assess the relative business value each feature will provide and prioritize them
- Evaluate the current business processes and propose improvements/new solutions
- Elaborate the software requirements from the high level ideas given by the business users
- Gather the supporting information for the requirements
- Ensure the non-functional requirements are handled
- Handles time consuming activities (like details out the acceptance criteria) which in turn gives more time to the business users to focus on high level ideas and abstract requirements
- Helps in stakeholder management and product implementation strategy
- Provides training to the target audience and Level 2 support
- Acts as business user’s representative for the development teams
Some of the responsibilities overlap with the traditional BAs. However, the most important responsibility is to convey the prioritized requirements to the development teams face-to-face rather than writing pages and pages.
Moreover, the agile BA is full time available for the development teams to clarify a requirement, to solve a doubt, to give a glimpse of future requirements.
Apart from all the responsibilities above, agile BA also helps in project and resource management. Agile BA reviews the existing business process, proposes changes/improvements to the existing processes, and in turn creates new Business Cases, which lead to additional projects and funding.
Agile BA is more than just a BA. Agile BA takes all the roles from Analyst to Facilitator.
The most important advantage in having a full time agile BA, that outweighs all the other advantages, is that the business user or product manager has someone as a partner, someone who can fill the gaps, someone who can review and highlight the dark spots, someone who can provide alternate solutions and bring a different perspective, someone to depend on.
This article is based on the book "The Power of Agile Business Analyst" by "Jamie Lynn Cooke".
Author: Saurabh Shah, Business Analyst