Since many years Business Analyst has played an important role in the field of software development. In a typical “Waterfall” Software Development Life Cycle (SDLC) model, a Business Analyst played a prominent role in the Requirements Engineering phase, ensuring high-level of quality before requirements are signed off and handed over to the Development team. Increasingly gaining more popularity in the past decade, the widespread acceptance and adoption of Agile methodology as the model of choice with its incremental, iterative, and adaptive process, the traditional role of a Business Analyst is being challenged and I feel there is a need to revisit this role within the context of Agile development methodology.

Source: https://www.scrumalliance.org/agile-resources/scrum-roles-demystified

Agile frameworks, particularly Scrum, does not specifically define the role of a Business Analyst, instead they refer to the Product Owner role as one of the stakeholders in the development process that represents the business/customer and ScrumMaster, a role that has no equivalent in a typical Waterfall SDLC. From my experience, Business Analyst is often assumed to be part of the Agile Scrum team and is acting as a ‘glue’ to bridge the gap between the Product Owner and the Development team. In this article, we’ll refine the role of a Business Analyst in a typical Agile Scrum team.

1)Bridging the Gap Between Product Owner and the Team: In Agile Scrum process, the Product Owner is representative of the business/customer and ensures that the development team is delivering value and work is prioritized accordingly. He takes the responsibility of communicating between the senior stakeholders, managing the product backlog’s and providing a clear direction/product vision to the team.Though the Business Analyst may not have a complete authority as a Product Owner, he can support the Product Owner in some of the above mentioned tasks, in agreement and aligned with the Product Owner and the team’s expectations.

2)Communicating Customer’s Needs and Wants: The Business Analyst is an extension of the Customer. He/she needs to be able to ‘think/behave’ like the Customer. Sometimes even better than the customer understand themselves! Business Analyst needs to be aware and differentiate between needs and wants and this perception needs to be communicated with the team. What I like here is if a BA can show an example through story-telling using analogy or using real-life examples. Story really sticks with people, especially Developers/Software Engineers who often sit far away from the customer.

3)Active Participation During the Development Process: There needs to be constant communication between the team and the Business Analyst to make sure the team is working on the right things at the right pace. As a Business Analyst, I would like to be always on top of the stories/tasks the team is currently working on. This way I am always talking on the same pace as the Developers and Testers on a day-to-day basis. Questions or issues raised can be quickly addressed in a timely and efficient manner.

4) Setting the right expectations: Agile manifesto embraces and expected changes by the customers. As a Business Analyst, this often presents its challenges and opportunities. On one hand the BA would like to please the customers/Product Owner, but on the other hand the BA needs to protect the team. He must handle these situations strategically and find the right balance. In my experience, empathy and transparent communication between the stakeholders is key to handle such situations. This is where a great BA shines in being able to manage the right expectations elegantly.

5)Identifying Impediments and Roadblocks early: Anyone in an Agile team can be an acting Scrum Master, including the Business Analyst. Once the team is in the middle of a development phase (Sprint), a BA can help out to offer help, come up with creative problem solving options/ideas, or escalate accordingly to the Product Owner or right stakeholders. What separates a great BA, though, is someone that can see potential roadblocks (technical or business-process related) early in the discovery phase, long before development started.

6) Active Participation in Testing: Business Analyst’s input and participation during the testing phase is of immense help to the team. His early insights are valuable in defining test cases with the team, either at unit-level testing with the Developer or system-level with the Tester/end users. People respect what you inspect. I hate to admit it myself, but this is something that I really enjoy doing. There is no better way of learning a new system or technology, whatever it is, than actually doing it together with your team.

7)Awareness Of Technology Stack: To have an edge on the product knowledge, it is of great value to understand the technology stack used to build the product. Knowledge of the architecture and technology stack gives a clear and methodical view of requirements traceability, implementation of requirements into software codes, and finally into product features. This technical knowledge will assist you to communicate with the team members working on your user stories better.

Conclusion: To conclude, a Business Analyst can be of great assistance to the Product Owner and the team in an Agile Scrum delivery model. Understanding the needs and wants of customers, a great BA is able to to communicate these eloquently to the team, ensuring the customer’s point of view is always considered during requirements elicitation and features development. Active participation in all phases of the software development also benefits the BA and the team in the long run. And finally, knowledge of the relevant technology stack and system architectures gives Business Analyst an edge to this role as it provides a strong technical foundation in the product knowledge.