What Is AgileBA, and Who Actually Needs It?

A business analyst joins a delivery team that has recently gone Agile. The stand-ups are new, the board is new, the language is new. Within a fortnight someone asks the question that tends to surface once the initial novelty wears off: is there a qualification for this, or is a BA just expected to pick it up as they go.

It's a fair question, and it doesn't have an obvious answer. Most of the visible Agile certifications are built for project managers. AgilePM covers delivery management. PMI-ACP covers a broader Agile mindset for anyone running projects. Scrum certifications sit inside the Scrum framework specifically. None of them are written for someone whose actual job is eliciting requirements, prioritising a backlog, and translating business need into something a delivery team can build. That gap is exactly where AgileBA sits, and it's precisely why so many BAs end up either ignoring the qualification question entirely or picking the wrong certification because it happened to be the one their organisation already ran.

AgileBA is a certification from APMG International, built with the Agile Business Consortium, and rooted in the same DSDM foundations that underpin AgilePM. That shared heritage matters. AgileBA isn't a generic Agile literacy course bolted onto the business analyst title. It's a specific discipline for applying business analysis, requirements elicitation, prioritisation, and stakeholder management, inside an iterative, timeboxed delivery environment rather than a traditional sequential one. Where AgilePM teaches how to run Agile delivery, AgileBA teaches how to do business analysis within it. The two are designed to complement each other, and organisations that adopt AgilePM often find they need AgileBA sitting alongside it for the qualification to actually work at team level.

The structure reflects that focus. The Foundation exam is closed book, forty minutes, fifty multiple-choice questions, with twenty-five correct answers needed to pass. It tests whether a candidate understands the principles, the terminology, and how DSDM-based Agile analysis actually functions, not whether they can recite a framework diagram from memory. The Practitioner exam goes further. It's scenario-based and open book, restricted to the official manual, and it asks candidates to apply the approach to a realistic situation rather than answer questions about it in the abstract. That distinction tends to catch people out. Candidates who treat Foundation as the whole qualification often assume Practitioner will be a formality, and then find themselves working through an unfamiliar scenario under time pressure with no prior practice applying the material that way.

Consider a business analyst moved from a waterfall-heavy public sector programme onto a newly formed Agile delivery pod. Her instinct, built over a decade of experience, is to produce a comprehensive requirements document before development starts. Three weeks in, she's still writing it while the team is already two sprints into building something else entirely. Nobody told her the requirements process itself had to change shape, not just the meeting cadence around it. That's not a failure of effort. It's the gap AgileBA exists to close: the specific mechanics of how requirements get captured, prioritised through techniques like MoSCoW, and refined iteratively as the product itself evolves, rather than fixed once at the start and defended from there.

The practical effect shows up in how a BA structures their week, not just their vocabulary. Under a traditional approach, requirements gathering is largely front loaded: workshops, sign off, a baseline document that changes only through formal control. Under DSDM based Agile analysis, requirements are captured at a level of detail that's just enough to start, then refined continuously as each timebox delivers something the business can actually react to. A BA trained this way learns to work comfortably with deliberate ambiguity early on, trusting that later iterations will sharpen what a fixed upfront document tries and often fails to guess correctly in one pass. Without that training, the instinct is to treat any incomplete requirement as a risk to be closed down immediately, which is precisely the behaviour that slows an Agile team back down to waterfall pace without anyone quite deciding that's what should happen.

There's also a stakeholder management dimension that catches experienced BAs off guard. In a traditional programme, the BA is often the single conduit between business stakeholders and the delivery team, managing that relationship through formal documentation and change control. In an Agile environment, stakeholders are expected to engage far more directly and far more often, through showcases, backlog refinement sessions, and short feedback loops. AgileBA covers how to facilitate that shift without losing the rigour that made the traditional approach trustworthy in the first place. That's a genuinely different skill from writing a good requirements specification, and it's one most BAs have never been formally trained in, because until relatively recently there wasn't a certification that addressed it directly.

Who actually needs it is narrower than the marketing around Agile certifications tends to suggest. It's for business analysts and business-facing roles working inside, or moving into, an Agile or hybrid delivery environment, particularly where DSDM or AgilePM already sits in the organisation's toolkit. It's less relevant for someone whose role is pure delivery management, since that's what AgilePM already covers, and it's not the right first step for someone still deciding whether they want a BA-shaped career at all. Successful candidates can also claim the Business Agility Professional Level 1 Explorer title through the Agile Business Consortium, which is a reasonable marker of genuine competency rather than a completion badge, precisely because the Practitioner exam demands application, not recall.

The honest answer to that stand-up question, then, isn't that a BA should simply absorb Agile working by osmosis, nor that any Agile-flavoured certificate will do. It's that the role changes shape enough under Agile delivery to warrant a qualification built specifically for it, and AgileBA is that qualification, not a substitute for AgilePM and not optional colour on a CV that already lists PRINCE2. If you're weighing AgileBA against the frameworks your organisation already runs, or trying to work out where it fits alongside a PM-focused qualification your team already holds, get in touch about your AgileBA training options and we'll talk through what actually fits your role.

Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.