If you are sitting at the start of a project right now and someone has asked you to recommend an approach, the Agile vs Waterfall methodologies debate is probably already on the table. Before you default to whatever your organisation used last time, it is worth making a deliberate, evidence-based call. I have seen projects fail not because the team lacked skill, but because they chose a delivery method that was fundamentally at odds with the nature of the work. This guide will help you avoid that.
I am not going to tell you that Agile is always better, or that Waterfall is outdated. In 25 years of BA practice across government, utilities, health, education, and enterprise environments, I have used both, and I have used neither in their pure form. What I will give you is a structured way to think through the choice, a real example of where that choice got complicated, and a clear view of what each methodology actually demands from you as a BA.
What Each Methodology Actually Requires You to Do
The practical difference between Agile and Waterfall is not just about sprints versus Gantt charts. It is about when certainty is required, and from whom.
- Waterfall demands upfront certainty. Requirements must be defined, signed off, and baselined before development begins. Your job as a BA is to elicit, document, and validate everything before the build phase starts. If you are working on a Waterfall project, the BA artefacts you produce carry significant weight because they become the contract between the business and the delivery team.
- Agile distributes certainty across the delivery cycle. You do not need to know everything before you start, but you do need enough to fill the backlog meaningfully. The BA role shifts toward continuous elicitation, story writing, and acceptance criteria definition in close partnership with the product owner and development team. If you want to understand how that role operates in practice, the Agile Business Analyst guide covers it in depth.
- Waterfall suits fixed-scope, fixed-budget, regulated environments. Think infrastructure upgrades, statutory compliance systems, or projects where the end state is legally or contractually defined before a single line of code is written.
- Agile suits evolving scope, discovery-led work, and stakeholder environments where priorities shift. Think product development, customer-facing digital services, or any project where the business genuinely does not know exactly what it wants until it sees something working.
- Hybrid approaches exist and are legitimate. A structured requirements and design phase followed by iterative delivery is a recognised pattern, not a compromise made by teams who could not commit to either approach.
Agile vs Waterfall: A Direct Comparison
| Factor | Waterfall | Agile |
|---|---|---|
| Requirements timing | Defined and signed off upfront | Progressively elaborated throughout delivery |
| Change tolerance | Low; changes trigger formal impact assessment | High; change is expected and accommodated in sprint planning |
| Stakeholder involvement | Heavy at the start and at review gates | Continuous; stakeholders participate in reviews and retrospectives |
| Delivery of value | At the end of the project | Incrementally, at the end of each sprint or iteration |
| BA documentation style | Comprehensive upfront documents (BRD, FRD, use cases) | Lightweight, just-in-time artefacts (user stories, acceptance criteria) |
| Risk profile | Risk concentrated at delivery; late discovery of issues is costly | Risk distributed across sprints; issues surface and are resolved earlier |
| Best fit | Regulated industries, fixed contracts, infrastructure | Product development, digital services, innovation projects |
| Team structure | Sequential handoffs between specialist teams | Cross-functional, self-organising teams working in parallel |
A Real Example: When the Methodology Choice Became the Problem
A few years ago I was brought onto a project at Organisation B, a mid-sized public sector body that was replacing a legacy case management system. The project had been scoped and contracted as Waterfall, with a fixed price and a defined requirements phase followed by a build phase. I was engaged to lead the requirements elicitation and produce the Business Requirements Document.
About six weeks into the requirements phase, it became clear that several of the key operational stakeholders had never actually agreed on how the new system should handle a particular category of cases. They had assumed the other team had made the decision. I documented the gap, raised it in the steering group, and recommended we extend the requirements phase by three weeks to resolve the ambiguity before it became a build problem.
The project sponsor pushed back hard. In their view, extending the timeline was not acceptable because the contract with the vendor was fixed and the go-live date was tied to a statutory reporting cycle. The sponsor wanted me to make a decision on behalf of the business and document it as an assumption. I refused to do that without at least one more structured workshop, because I knew that an assumption about case routing logic in a regulatory system would come back as a defect in UAT and cost far more to fix than three weeks of elicitation time.
We eventually ran a compressed two-day workshop, resolved the ambiguity, and updated the BRD. The build phase proceeded without that particular issue surfacing again. But the friction taught me something important: Waterfall does not eliminate uncertainty. It just means that any uncertainty you fail to surface in the requirements phase will resurface later, at a much higher cost. The methodology was right for the environment, but only if the requirements phase was given enough time and rigour to do its job properly.
Had this been an Agile project, the case routing logic could have been deferred to a later sprint and resolved iteratively. But the fixed-price contract and statutory deadline made Waterfall the only viable framework. The lesson is not that one method is better. It is that the method has to match the constraints of the environment, and the BA has to be honest about what those constraints mean for the work.
How to Make the Call on Your Current Project
When I am advising on methodology selection, I work through a short set of diagnostic questions with the project sponsor and delivery lead. You can do the same right now.
- Are the requirements stable and well-understood? If the business can articulate what they need in enough detail to sign off a specification, Waterfall is viable. If discovery is still ongoing, Agile protects you from premature commitment.
- Is there a fixed contract or regulatory constraint on scope? Fixed-price contracts, compliance mandates, and statutory deadlines all push toward Waterfall because they require defined deliverables and formal sign-off points.
- How available are key stakeholders? Agile demands consistent, engaged stakeholder participation across the full delivery cycle. If your sponsor is available for a kick-off and a go-live but not much in between, Agile will struggle. Waterfall front-loads that engagement in a way that suits time-poor senior stakeholders.
- What is the organisation’s delivery maturity? Agile requires disciplined backlog management, regular retrospectives, and a product owner who can make prioritisation decisions. If those structures are not in place, the label “Agile” will be applied to work that is actually chaotic rather than iterative.
- Is there appetite for a hybrid? A structured requirements and design phase, followed by iterative sprint-based delivery, is a legitimate pattern. It works particularly well when you need upfront approval for budget or scope but still want to deliver incrementally. Understanding what BA deliverables look like in an Agile context will help you design the transition point between phases.
What the BA Role Looks Like in Each Approach
The methodology you choose shapes everything about how you operate day to day. In Waterfall, much of my energy goes into comprehensive upfront documentation. That means a detailed BRD, often a Functional Requirements Document, use cases, and a requirements traceability matrix. The quality of those documents determines the quality of the build. Understanding the difference between a BRD and an FRD matters more in Waterfall than in Agile, because both documents are formal deliverables that will be reviewed, signed off, and referenced throughout the project lifecycle.
In Agile, I spend far less time writing comprehensive specifications and far more time in conversation. Writing user stories, defining acceptance criteria, facilitating backlog refinement, and working alongside developers to clarify intent as they build. The documentation is lighter but the collaboration is heavier. Neither approach is easier. They are just different in where the effort concentrates.
The Hybrid Model Is Not a Compromise, It Is a Design Decision
I want to push back against the idea that choosing a hybrid approach means you could not commit to either methodology. In many of the most complex environments I have worked in, a hybrid was the right answer by design. Government digital transformation programmes, for example, often require formal business case approval and a defined scope before funding is released, but benefit enormously from iterative delivery once that approval is secured. A structured initiation and requirements phase followed by Agile sprints is not a fudge. It is a deliberate choice that respects both the governance requirements of the organisation and the delivery benefits of iteration.
The hybrid model does require clear thinking about where the handover point is, what artefacts are produced in each phase, and how the product owner and BA roles interact across the boundary. That is worth planning explicitly rather than assuming it will work itself out.
Whatever method you choose, the decision should be documented in your Business Analysis Approach Document so that stakeholders understand the rationale and the implications for how requirements will be managed throughout the project. Methodology choice without documented rationale is just a guess with extra steps.
Agile and Waterfall are both mature, proven methodologies with genuine strengths, and the most valuable thing you can do at the start of a project is resist the pressure to default to whichever one the organisation used last time. Make the choice based on the actual constraints in front of you, document your reasoning, and be honest when the environment is pushing you toward a hybrid. The methodology should serve the project, not the other way around.
Frequently asked questions
What is the main difference between Agile and Waterfall methodologies?
Waterfall follows a sequential, phase-by-phase process where requirements are fully defined before development begins, while Agile delivers work in short iterative cycles that allow requirements to evolve throughout the project. The key practical difference is when certainty is required: Waterfall needs it upfront, Agile builds it progressively. Both are mature, legitimate approaches used across industries worldwide.
When should I use Waterfall instead of Agile?
Waterfall works best when requirements are stable and well-understood, when there is a fixed-price contract or regulatory constraint on scope, or when the organisation needs formal sign-off at defined milestones. It is particularly well-suited to compliance-driven projects, infrastructure replacements, and statutory reporting systems where the end state must be defined before work begins. If stakeholder availability is limited to the start and end of a project, Waterfall also tends to be more manageable.
Can you combine Agile and Waterfall methodologies?
Yes, a hybrid approach is a recognised and legitimate delivery pattern, not a compromise. A common model uses a structured Waterfall-style requirements and design phase to secure funding and approval, followed by iterative Agile sprints for delivery. The important thing is to plan the handover point deliberately and document what artefacts are produced in each phase.
What does a business analyst do differently in Agile vs Waterfall?
In Waterfall, the BA produces comprehensive upfront documentation including a Business Requirements Document, Functional Requirements Document, and use cases that are formally signed off before development begins. In Agile, the BA focuses on writing user stories, defining acceptance criteria, and supporting continuous backlog refinement in close collaboration with the product owner and delivery team. The workload does not reduce in Agile, it redistributes from document-heavy upfront work to conversation-heavy ongoing work.
What are the risks of choosing the wrong methodology for a project?
Choosing Waterfall on a project with unstable requirements means you will spend months building against a specification that no longer reflects what the business actually needs. Choosing Agile in an environment without engaged stakeholders, a capable product owner, or a disciplined backlog process often produces chaotic delivery rather than genuine iteration. The methodology has to match the constraints of the environment, not just the preferences of the team.
Try Ash, Your Virtual BA
If you are working through a methodology decision right now and need to document your approach, Ash can help you think it through and produce the supporting analysis. Whether you are scoping a Waterfall requirements phase, structuring a hybrid delivery model, or writing the Business Analysis Approach that justifies your recommendation, Ash is built on real BA practice and will guide you through the process step by step. Try Ash Virtual BA and get your approach documented today.
Further reading
- Waterfall Methodology Agile Approach | PMI
- Agile vs. Waterfall: Pros & Cons, Use Cases, & More | Scrum.org
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.