Are you a BA in an Agile project or an Agile BA?

In an agile environment, particularly in the case of large scale globally distributed teams, a Business Analyst (BA) does not just have to be ‘a universal communicator’ of requirements, but also has to act as the product owner. There is a school of thought that opposes this transition. The crux of their argument is that a BA acting as a product owner may deviate from his core responsibilities while trying to play the role of a product owner.

Our years of delivering complex global projects however, have led us to believe that by stepping into the shoes of the product owner, a BA can add tremendous value to an agile project. This transformation is especially important for companies moving from ‘tending towards Agile’ to ‘purely agile’.

An agile roleplay

Having an agile BA in a project in no way implies that we do away with the product owner. It only means that the responsibilities get shared between the product owner and the BA. We believe that a BA in an agile model should aim to develop competencies in the area of product strategy, technology stacks and relationship building over and above the functional, requirement gathering aspect of the role.

 

Broadly, an agile BA should:

Be a part of the strategy
Typically, a BA would take the requirements from the stakeholders and then document, analyse and communicate them. This would limit his vision to the set of requirements at hand. By being part of the strategy, an Agile BA looks beyond requirements to analyse the business, the competition and more importantly, the product strategy. They help the product owner prioritize user stories such that minimum marketable product can be rolled out faster.

In many projects, we found that the stakeholders involved (Sales & Marketing, Business Groups, and Operations) ‘knew’ what they needed but there was no common direction.
Formulating a strategic direction and consensus building requires an interplay between all the stakeholders. An Agile BA can facilitate the communication here.

Understand technology
A BA in a traditional operating model would generally stay away from the technology being used in the project with functional requirements being the only point of interest. However, like the product owner, an Agile BA should also contribute to or at least be part of the discussions around technology. This ensures that while analysing user stories, an Agile BA would be able to take into account the risks stemming from technological challenges.

With modern technologies like cloud, analytics and IOT becoming ubiquitous, our experience shows that a basic understanding of major platforms and trade-offs therein help the BA contribute to the product roadmap and non-functional requirements.

Make decisions faster
With thorough knowledge of business strategy and technology, the Agile BA would be equipped to take real time decisions. Majority of requirement-based clarifications can then be done at the implementation level and only filtered queries would reach the product owner. This eventually saves a lot of time with faster turnaround, which is key to an agile project.

We believe that besides backlog grooming, an agile BA should be able to manage scope, do release planning and evaluate UX decisions like the extent of multi-screen support etc.

Become a trusted partner
Once the BA steps into the shoes of a product owner and starts executing allied tasks, the product owner and the business stakeholders will start seeing a trusted partner in the Agile BA.

We have seen that as the product owner gets comfortable with the role of an Agile BA, he off-loads some of his responsibilities and is able to spend more time analysing business growth which ultimately benefits the overall business.

The following table gives a snapshot of different focus areas and a comparison of the roles played by a traditional BA and an agile BA.

International Institute of Business Analysis (IIBA) also highlights the need for the changes in the role of a BA in the latest version of the BABoK™ (Business Analysis Body of Knowledge).

In several projects at Nagarro, we have taken our client relationship to the level where the product owner simply provides a one line high level requirement and our Agile BAs takeover from there. They drill down the one liner to finer requirements and build the product backlog, groom it, plan releases and even perform the user acceptance testing.

This is what enables us to play the role of a true partner to our clients and help drive their success along with ours.

With contribution from: Mohit Grover.