The role of the Business Analyst in Agile Projects


I still find that many engineers and even decision makers planning large-scale Agile Transformation are unaware of what a Business Analyst does and how critical their value can be to a project. So today let’s take a closer look at the often misunderstood job definition of “Business Analyst” and what makes a BA outstanding in their field.

The BA is a central role within the organization bridging the domains of R&D and business. They are big picture type of people who define and prioritize requirements, and provide the needed communicative glue between individual units so that information flows smoothly.

To hold the BA accountable they are usually also involved in QA, or even understand the challenges of testing. While a BA is not a tester they should be able to define what the quality metrics of the projects are in order to meet the defined requirements and objectives within the projects constraints. But in practice testing has already moved towards total automation and within development is part of the continuous integration and delivery teams.

In smaller organizations the BA would hold a hybrid position as Product Owners who take on the additional responsibilities. As with anything the bigger and more structured the companies are, the better refined the definition of individual roles.

A good BA is probably a little of all of the above. They should be able to draw from past experience in varying previous roles that allows them to understand the different (human-)interfaces (testing, QA, development) which they’re dealing with. That’s why I called them big-picture type of people above.

The difference between BA and Product Owner is that the former is the business main delegate and accountable to the business. The BA is accountable to both the business and the projects and so wearing additional hats. More than any other role, their central position allows them to tap into many knowledge pools (information silos) and different parts of the organization that are usually hidden to others. Hopefully that makes them one of the most knowledgeable people within a company. A switched-on, strong performing BA is a valuable consultant who can bring additional viewpoints to the table and acts as a trusted advisor to both the business and the project.

From that a career aspect the question is when should you chose to move into a BA role? I’d say that it is an awesome career decision for somebody who wants to look beyond the SDLC and understand as much as possible of why and how things work the way they do. Most companies will hire a BA who has experience in at least one other field (e.g. somebody who moved from development/testing into QA) and is also passionate about the companies chosen development methodologies (DevOps/Agile, Lean, etc). It’s rarer to see somebody with a non-technical background move towards BA role because a key requirement is to understand also the underlying engineering challenges.

So now that we looked at where the BA overlaps to other domains, what are the specific tasks which make a BA an actual BA?

  • The BA assists the business and the project to define the problem and articulate a vision before they’re translated into functional requirements. OK this sounds a bit blah, so what we mean here with “articulating vision” is that a BA should be able to picture the product and have a good idea how the end-user will interact with it. This is why we see many UE/UX aspects as an important requirement within BA jobs.

  • Generate requirements by talking to as many different stakeholders as possible and even conducting cross-functional requirements workshops with clients. E.g. here.

  • Develop User Stories and precisely define associated acceptance criteria (“Definition of Done”) so the delivery team will know when they’re done. This is sometimes done by Product Owners but the BAs input would be beneficial for them.

  • In some bigger firms with lots of projects the BAs will move on to the next projects once the developers start with the sprint while in smaller companies the BA will stay on throughout the whole duration until product delivery. In this case they might don on high-level QA “hat” to ensure the product has actually been delivered as imagined.

  • Conduct gap analysis of the business processes and suggest process improvements.

  • Map the gaps between the available input to what is still required. Ensure the missing input becomes available in time for the teams to commence implementation.

  • Create user-stories, wire-frames, mock-ups or assist UE experts envisioning the final product.

  • Understand the dependencies and flow of requirements and support the business by discussing how changes in requirements will impact the project time-line. Alert decision makers early enough of potential pitfalls:

  • Assess the impact and risk to ongoing projects stemming from changes to current processes or modifications of established practices. 

  • A successful BA does not live in one specific BU or silo (or worse in a cosy bubble together with the Product Owner), but they reach out to individuals from many departments and pull in as much information as possible. Communication skills and understanding that not every problem is a technical problem are key differentiators for a successful BA.

In conclusion, the BA is a vital role especially in bigger organizations who have moved to agile practices. While early critics of Agile have pointed out that Agile was only a dirty way to throw your product over your clients proverbial fence as quickly as possible, having a BA in your organization is a great way to add accountability to Agile teams without stepping on your developers toes. A good BA greatly improves your internal communication and how well you harness the hidden pockets of know-how from individual BUs and R&D’s.

From what I have seen, a dedicated BA allows “old” companies transition to Agile practices more smoothly than when a company transforms by simply saying “let’s get rid of all our Project Managers and put responsibility for QA, requirements, and UE/UX into the hands of our developers”.

Valbonne Consulting provides Research & Consulting for emerging technologies in Internet/Web of Things (WoT/IoT/M2M) and Emerging-Tech. We specialise in decentralisation, security and privacy. We work across a variety of traditional industry verticals (Telecommunications, Automotive, Energy, ...). We support Open Source and technologies built on open standards.

Joachim Bauernberger

Passionate about Open Source, GNU/Linux and Security since 1996. I write about future technology and how to make R&D faster. Expatriate, Entrepreneur, Adventurer and Foodie, currently living near Nice, France.

Leave a Reply

Your email address will not be published. Required fields are marked *