Agile demystified: What it actually demands of a BA
Yesterday, we examined Waterfall in depth: the phases, the deliverables, the scenarios where it excels, and the mistakes that trip BAs up. Today, we turn to Agile, and I want to start with something honest.
Agile is the most misunderstood methodology in our profession. Not by people who have never encountered it, but by practitioners who work inside it every day and have quietly lowered their standards in its name.
What Agile Is Not
Before we examine what Agile is, it is worth spending a moment on what it is not because the misrepresentations are common enough that they are actively damaging BA practice in many organisations.
Agile is not an excuse to skip analysis. It is not a licence to produce no documentation. It is not a methodology where the BA role is less demanding or less critical than in Waterfall. And it is most definitely not a framework that makes project delivery easier; it makes it more difficult.
I have observed BA practitioners in Agile environments who have gradually reduced their practice to attending ceremonies and responding to Slack messages. No structured elicitation. No maintained backlog quality. No product vision documentation. No acceptance criteria that would withstand a tester's scrutiny.
They are not practising Agile BA. They are practising the absence of BA, with a sprint cadence as cover.
Genuine Agile BA practice is one of the most intellectually demanding roles in project delivery. Here is what it actually involves.
The Agile Manifesto
The four values of the Agile Manifesto are worth examining from a specifically BA perspective, because each one has direct implications for how you practise your craft.
Individuals and interactions over processes and tools
For the BA, this value is a mandate for strong stakeholder relationship management. Your most important analytical tool is not a template, a tool, or a process. It is your ability to create conversations that surface what stakeholders actually need, as distinct from what they say they want. This requires trust, and trust requires investment. The Agile BA builds stakeholder relationships as a continuous practice, not as a phase-gate activity.
Working software over comprehensive documentation
This is the value most frequently used to justify poor BA practice, and it deserves the most careful reading. The manifesto does not say documentation has no value. It says that documentation which does not contribute to working software being delivered to users is of lower value than the working software itself.
For the BA, this means calibrating your documentation to what serves delivery. User stories must be precise enough to build from. Acceptance criteria must be specific enough to test against. Process documentation must be current enough to be reliable. What gets reduced is not the quality of BA work; it is the volume of BA artefacts that nobody reads.
Customer collaboration over contract negotiation
In practice, this means that your stakeholder relationship is ongoing and collaborative, not a series of formal requirements sign-offs followed by silence. The Agile BA is continuously in dialogue with the business: refining understanding, surfacing new information, and translating evolving needs into actionable backlog items.
Responding to change over following a plan
This does not mean there is no plan. It means the plan is a living document, not a contract. For the BA, responding to change analytically means processing new information through a structured lens: What is the business impact of this change? What does it displace or affect in the existing backlog? What decisions does the Product Owner need to make? Change is information. Your job is to process it, not resist it.
The Scrum Framework & The BA's Role in Every Ceremony
Most Agile delivery uses the Scrum framework. Understanding your specific contribution to each ceremony is the difference between being a passive participant and a driving force in the team's effectiveness.
Sprint Planning
Your work before sprint planning is what determines how effective sprint planning is. User Stories must be refined, sized, and acceptance criteria must be complete before they enter the session. If the team is spending sprint planning clarifying what a story means, it is not sprint-ready, and that is a BA's accountability.
During sprint planning, you are the business context expert. When the team asks whether a technical implementation decision is acceptable from a business perspective, you answer. When a story's scope needs to be adjusted to fit sprint capacity, you negotiate what can be deferred without losing the story's business value.
Daily Standup
Your standup contribution is brief, but your listening is critical. Blockers that are stated as technical problems are frequently, at their root, requirements problems. A developer who says 'I'm not sure how to handle the case where the user has two active accounts' is telling you that your acceptance criteria did not cover that scenario. Address it today.
Sprint Review
This is the most important elicitation session of the sprint, and most teams do not treat it that way. When stakeholders see working software, even incomplete software, they tell you things they could not have told you in a workshop or an interview. They see interactions they did not anticipate. They identify gaps they did not know existed. They change their minds about priorities in ways that are grounded in reality rather than abstraction.
The BA's role in the sprint review is not just presenting completed work. It is actively facilitating a feedback conversation and capturing every piece of new information for conversion into backlog items.
Backlog Refinement
This is your primary working session as an Agile BA. You are breaking down epics into user stories of appropriate size, writing acceptance criteria in testable, observable, business-language terms, applying MoSCoW prioritisation in collaboration with the Product Owner, estimating complexity with the development team, and ensuring that the top of the backlog is always at least two sprints deep and fully sprint-ready.
A well-maintained backlog is the clearest indicator of BA quality in an Agile environment. It is your primary deliverable.
Sprint Retrospective
The BA participates as a full team member in retrospectives, reflecting on process, communication, and ways of working. If requirements quality was a factor in any sprint issues, the retrospective is where you surface it, own it, and commit to addressing it.
Three Real-World Scenarios Where Agile is the Right Call
Scenario 1: Digital Banking Application
A retail bank is developing a new mobile banking application. Competitor apps are releasing new features on a monthly cadence. Customer expectations shaped by fintech challengers are evolving rapidly. The bank's own research shows that customers prioritise features differently from what the product team anticipated.
In this environment, specifying all requirements upfront would be an expensive fiction. By the time a full specification was written, reviewed, approved, and developed against, the competitive landscape and customer expectations would have shifted. Agile's iterative delivery, sprint review feedback loops, and adaptive backlog management give the product team the ability to respond to reality as it unfolds.
Scenario 2: Operational Process Transformation
A logistics company is transforming its end-to-end order management process, consolidating four legacy systems into a single integrated platform. The operations team knows the outcomes they need: faster order processing, fewer manual interventions, and real-time visibility, but they cannot specify the exact system behaviour upfront without seeing how the integrated platform actually works.
Agile's rhythm of building small increments, demonstrating them to operational stakeholders, and refining based on their experience of working with real software matches the pace of this kind of transformation. Each sprint delivers something usable and generates insight that shapes the next sprint's priorities.
Scenario 3: Innovation Product in an Emerging Market
A technology company is building a product for a market segment that does not yet fully exist. Target users are not precisely defined. The feature set is hypothetical. The business model is being tested alongside the product itself. In this context, a comprehensive requirements specification would be creative writing.
Agile's emphasis on validated learning over comprehensive planning is not just appropriate here; it is the only intellectually honest approach. The BA's role in this environment is to design the learning experiments, capture what each sprint teaches about user behaviour, and translate those insights into evolving product direction.
Where Agile Quietly Fails & The BA's Warning Signs
Warning Sign 1: The Backlog Has No Coherent Vision
A product backlog should not be a flat list of feature requests. It should tell a story about what the product is becoming with epics organised around user outcomes, stories that clearly connect to business objectives, and a priority logic that is visible and defensible. When you look at a backlog and cannot explain why item 15 is more important than item 47, the BA work has not been done.
Warning Sign 2: Acceptance Criteria Written as Technical Tasks
Acceptance criteria must describe observable, verifiable business behaviour, not technical implementation steps. 'Update the database record' is an implementation task. 'When a customer updates their address, the change is reflected across all relevant systems within 30 seconds, and the customer receives a confirmation notification' is an acceptance criterion. The distinction matters enormously in testing and in resolving disputes about whether a story is done.
Warning Sign 3: Sprint Reviews Without Real Stakeholders
A sprint review attended only by the delivery team is a ceremony, not a feedback loop. If business stakeholders are not present, the most valuable source of learning in the Agile cycle is absent. When stakeholder attendance is low, that is a signal to investigate, and the investigation usually reveals either that the sprint review format is not engaging, that the right people were not invited, or that there is a relationship issue between the delivery team and the business. All of these are BA problems to solve.
Go out and be successful.