The BA-DAY Blog

Read this Blog Post

Defining “Agile Business Analyst”: a challenge for BAs.

There are, for already some years, ongoing discussions about the understanding of what an “Agile Business Analyst” actually is, without a real consensus showing up. For some people, given the characteristics and competencies of a BA, the adjective “Agile” is redundant; for others, it is contradictory.

“Agile BA” looks like a pleonasm

In his post of 2014[i], Steve Blais gave an excellent overview of the disagreement that exists regarding the understanding of “Agile BA”. He also claimed that:

(…) a business analyst is, and really always has been agile.

Agility may be required in any environment and is not uniquely related to agile development; changes are inherently parts of a project; they may address different elements (irrational decisions, failures, occurring risks, invalid assumptions, new regulations, improved understanding, …) with frequencies more related to the environment than to the used project development approach.

Blais underlined that any good BA may recognize himself in the values of the Agile Manifesto and used this later to introduce the A.G.I.L.E. Business Analyst characteristics:

  • Adaptability
  • Goal orientation
  • Innovation
  • Leadership
  • Empathy

Some of the Underlying competences of a Business Analyst as referenced in the BABOK 3rd ed. (e.g. behavioral characteristics, communication and interaction skills) also provide further elements in favor of this interpretation.

“Agile BA” looks like an oxymoron

Typically, agile practitioners used to state that there is no Business Analyst in their team because there is no need for it; there is no need for detailed documentation and no room for such a role.

Looking at the way agile teams work, we may observe that BA’s responsibilities (requirements elicitation & management; solutions evaluation …) are distributed between different predefined roles and the distribution depends on the method in place (eg.: In Scrum, the Scrum Master act as a facilitator, the Product Owner is responsible for requirements management, …). This looks good in theory but may not fully apply in practice; some team members may be lacking crucial BA skills and the introduction of a BA into the team may be an excellent response to this issue. The BA may also foster communication and requirements identification associated with environmental factors that could be out of reach for team members.

Any hope about an agreement on a definition?

We may wonder if one time we would come to a common definition of an Agile Business Analyst and if the Linkedin discussion referred by Steve Blais will ever end. We may have some doubts, especially so long the two schools of thought have different outlooks; the first one referring to the BA as a practitioner and the second one referring to it as a role.

In her blog post, after provision of some reasons for having a BA in an Agile Team, Bonna choi


At the end of the day, the title doesn’t really matter. Each organization has its own terminology to call similar roles differently. What really matters is the kind of team dynamics needed to succeed with Agile.

While it may be difficult to get a shared definition of what an Agile Business Analyst is, we may identify Agile Business Analysis as the BA discipline commonly applied in agile development environments. The demand in this area is increasing and practitioners are developing, with more or less creativity, a large number of tools and techniques. Therefore, any organization (whatever its approach – agile or not), willing to identify, evaluate and adopt the most suitable tools or techniques, should definitely follow the latest trends in Agile Business Analysis.

[i] Blais, Steve (2014, January 21st). What is an AGILE Business Analyst? Retrieved from

[ii] Choi, Bonna (2013, May 22nd) Do we need a Business Analyst on an agile team? Retrieved from

4 Responses

  1. Thank you for this perspective on agile Business Analysis. I fully agree that the name of the role finally does not count, the efficiency with which a new solution becomes finally effective counts, i.e. this very much determines the success of the project. If agile people do not see the necessity of a BA, just re-brand him or her and call him (member of the) Product Owner (team). The real PO from the business is very often too busy for carefully managing requirements (prioritizing user stories in the backlog). He is typically in a – what I like to call it – part-time dilemma, i.e., he has not sufficient time besides his business role to fill his PO role with adequate dedication. This dilemma can be resolved by a BA wearing a magic PO hood 😉

    1. YJ

      The PO may be stretched between his business and project duties and face difficulties conciliating both. 😕 His availability, responsiveness and decision making may suffer from this 😐 ; the product quality and completion date have then a high probability to get affected (an agile approach would then lose its interest) 🙁 . Dealing with other stakeholders within and outside the organization is often time consuming; developing missing skills may also require some time and not present the expected ROI if not necessary on the long run; the delegation of all PO duties (except decision making) to a BA is a wise recommendation to which I fully adhere. 😎

Leave a Reply