How Do Business Analysts Fit Into Agile Projects?

Though the Agile Methodology is used heavily in software development domains, it has since spread into different sectors. With Agile comes a growing emphasis on equipping the development team, e.g. your software developers, content writers, engineers, designers, etc, with the information, tools, and direction they need to produce a tangible output within a fixed period of time, that is, sprints of typically 2 weeks. 

In any case, it would appear that with agile, the implementation/development team is set without a BA. Do they really need a business analyst in the mix? The answer is a resounding YES!

A Perfect Scrum Is NOT A Perfect Product 

What if you develop a software-as-a-service (SaaS) platform that no one in the world wants? How will you discover unsung problems in need of a solution you can produce? Who will take accountability for ensuring you don’t walk into a space that’s saturated with competitors? 

These are but a few questions that an agile business analyst will help answer to help the development team work through every sprint.

Determine What Users Need & Want

Be it software for internal purposes, a consumer-facing product, or a deliverable for a client, the business analyst will be in constant tune with the end users’ needs and wants. This translates into scrum in multiple ways.

The business analyst can help to ensure that the development team delivers on the insights of the client. The analyst must ensure that the client receives value. This could involve altering the scope of the work so as to get more accurate and relevant insights, with the Product Owner’s blessing.

In terms of software development, the business analyst may also own the responsibility of examining user analytics data, end-user surveys, and other data sources to ensure the new UI/UX delivers on expectations, especially if a UX professional is not part of the development team.

Champion the Product in the Organization

By understanding the product’s value to the organization, be it in terms of tapping into a growing market segment or in cutting operational costs, the business analyst can champion the product. Your development team members are occupied with actually designing and delivering the product, so they lack the bandwidth to defend or promote it across the organization. 

On the other hand, a higher level executive, while possessing clout, will not be able to champion it without access to the proof of its value.

The business analyst can produce proof and communicate the value of the product throughout the organization. In some cases, they can also network with major influencers, including upper management, to further the cause. By successfully championing the project, the analyst could help the project/product gain the organizational support/recognition it needs.

Align Development Team to Strategic Goals 

The point on ensuring the product meets the customer or end user's needs may be related to the fulfilment of strategic goals. In software development, this could mean omitting certain features that, while interesting in of themselves, are of limited utility to the intended end user. This move would result in reducing both your product’s time-to-market/deployment and use of resources. 

Act As Product Owner

Thus far, we’ve outlined the tasks that an Agile business analyst can do while operating inside or in concert with sprints. However, do they have a more formal role? It ultimately depends on each organization, but you can embed the business analyst very deeply into your implementation of the scrum framework. Your business analyst could be the product owner. The business analyst can operate as the gatekeeper for ensuring that client/market/organizational goals are met during development. The line between a product owner who serves as a decision-maker and a proxy who must report to someone else is thin. The communication between the business and the BA/Product owner has to be seamless to ensure decisions and key activities such as backlog prioritization can be achieved seamlessly, without putting the whole team at risk of miscommunication, delays, and potentially, low morale.

Author’s Bio

Greg Kellner spent over half a decade working in the tech industry. Besides learning new things about software and IT, one of his passions is writing & teaching about technology. He is working with PCM Canada and helps produce and edit content related to IT, covering topics such as hardware & software solutions for businesses, cloud technology, digital transformation, and much more.