In agile vs waterfall vs scrum, the real choice is between sequential and iterative delivery: Scrum is a framework inside Agile. Pick Waterfall when requirements are defined and fixed; pick Agile or Scrum when requirements may change.
The sections below explain how each approach works, then compare them side by side and turn the differences into decision criteria. For wider context on building software, see our software development guide.
How Agile, Waterfall and Scrum relate
The three terms sit at different levels, which is why comparing them directly causes confusion. Waterfall and Agile are approaches to organising work. Scrum is a specific way of practising one of them.
Accelo’s comparison describes Agile as an iterative approach that delivers work in smaller increments and adapts as requirements evolve. It describes Waterfall as a sequential approach in which teams complete predefined phases in order. Frameworks such as Scrum and Kanban apply Agile principles in different ways, but Agile itself is the broader philosophy. Saviom makes the same point from the Scrum side, calling Scrum a subset of Agile and one of its most popular frameworks.
The practical consequence is that “Agile or Scrum?” is rarely the real question. If you choose Scrum, you have already chosen Agile. The decision that carries risk is whether work should be planned in full up front and executed in order, or planned and adjusted in increments.
The Association for Project Management adds a useful framing: Agile and Waterfall exist on a continuum of techniques, to be adopted as appropriate to the goals and culture of the project. Treat them as ends of a scale rather than rival camps.
Waterfall: sequential phases and where it fits
Waterfall moves through predefined phases, and each stage is generally completed before the next begins. A typical project might progress through requirements, planning, design, execution or development, testing or review, delivery and maintenance, according to Accelo. Saviom puts the model at five to seven distinct phases in a linear sequence.
What makes it predictable
Waterfall treats scope as the driver and calculates the consequential time and cost, as the APM puts it. Accelo notes that budgets are often easier to estimate upfront. That makes the approach attractive when someone must sign off a fixed plan before work starts.
When to use Waterfall
Use Waterfall when the conditions that make a fixed plan reliable are actually present:
- Defined requirements. Accelo says Waterfall is often a better fit for projects with clearly defined requirements, fixed milestones or strict approval processes.
- Regulated work with a clear vision. Salesforce Ben describes it as best for projects with strict regulations, a clear vision and specific requirements.
- Stakeholders who do not need to steer during the build. Client involvement is minimal during the development phase, so the approach suits clients who want to agree the specification and then wait for delivery.
The cost of late change
The weakness follows from the mechanism. Once a project moves beyond a phase, major changes may require significant rework. Feedback is usually tied to milestones or review stages, so a wrong assumption can survive until a late checkpoint. Salesforce Ben also notes that Waterfall may not be as adaptable to change as Scrum. If you expect requirements to move, that is a reason to look elsewhere.
Agile: iterative delivery and its trade-off
Agile replaces the single long plan with short rounds of delivery and review. Accelo says it is generally better suited to projects where requirements may change or where frequent stakeholder feedback is valuable. The APM frames the underlying value as responding to change over following a structured plan.
The benefit is that new information reaches the plan early. The trade-off is the mirror image of Waterfall’s strength: because requirements can change, total project effort and final scope become harder to predict. Accelo reports that budgets can change as scope evolves. Agile suits teams and sponsors who accept that uncertainty in return for adaptability. It is a poor fit for a sponsor who needs a fixed price for a fixed scope on day one.
APM’s description of Agile commits resources over limited periods rather than fixing the whole scope in advance. That is a useful test for a sponsor: if they can fund and review work in limited periods, Agile is workable; if they must approve everything once, it is not.
Scrum: sprints, roles and events
Scrum gives Agile a fixed structure. According to Saviom, work is executed in fixed iterations called sprints, typically lasting 2 to 4 weeks. The rhythm and the defined roles are what separate Scrum from Agile in general, which names values and leaves the mechanics to the team.
Roles
- Product Owner. Acts as the bridge between the stakeholders and the development team and manages the product backlog.
- Scrum Master. Helps the team achieve the best results by organising meetings to address roadblocks.
- Development Team. Does the work that the sprint commits to.
The sprint cycle in order
- Sprint planning. Led by the Scrum Master, the team reviews the work the Product Owner wants completed in the sprint.
- The sprint itself. The team works within the fixed iteration, so the length of the sprint caps how much can be taken on.
- Sprint review. At the end of the sprint, the team demonstrates completed work to stakeholders, gathers feedback and refines the product backlog.
- Sprint retrospective. An internal meeting for the Scrum team after the review, focused on improving the process.
The review and the retrospective answer different questions. The review looks outward at the product and invites stakeholders in. The retrospective looks inward at how the team works. A team that holds only the first will improve its product but not its process.
Who Scrum suits
Scrum fits when stakeholder feedback is wanted at regular intervals and a Product Owner can prioritise the backlog between sprints. It adds overhead that a team with no access to stakeholders cannot use, because the sprint review depends on someone to review the work with.
Side-by-side comparison
The table lines up the three on the criteria that most often decide the choice. Scrum cells follow its place as a framework within Agile.
| Criterion | Waterfall | Agile | Scrum |
|---|---|---|---|
| What it is | Sequential approach with predefined phases completed in order | Iterative philosophy delivering smaller increments | Framework that is a subset of Agile |
| Rhythm | Five to seven distinct phases in linear sequence | Iterative cycles that adapt as requirements evolve | Fixed sprints, typically 2 to 4 weeks |
| Scope | More fixed | Flexible | Set sprint by sprint from the work the Product Owner wants completed |
| Budget | Often easier to estimate upfront | Can change as scope evolves | Follows Agile, so it is not fixed in advance |
| Feedback | Usually tied to milestones or review stages | Frequent and continuous | At the sprint review at the end of each sprint |
| Client or stakeholder role | Minimal during development | Frequent feedback is valuable | Product Owner bridges stakeholders and team |
Figures and descriptions are drawn from Accelo’s Agile and Waterfall comparison and Saviom’s Scrum and Waterfall article.
Decision criteria for choosing a way of working
Start with how stable the requirements are, because almost every other difference follows from it. The criteria below are ordered by how strongly they should sway the decision.
- Stability of requirements. Clearly defined requirements point to Waterfall; requirements that may change point to Agile. If you cannot say which describes your project, assume change is likely and keep the option to adjust.
- Regulation and approvals. Strict regulation and formal approval processes favour Waterfall’s phase-by-phase structure, according to Accelo and Salesforce Ben.
- Need for a fixed budget. If a sponsor needs a cost agreed before work begins, Waterfall’s upfront estimation is the stronger fit. If the sponsor can fund work in limited periods, Agile is viable.
- Stakeholder availability. Frequent feedback only helps if someone gives it. Choose Waterfall or a light Agile approach when stakeholders cannot attend regular reviews, and Scrum when a Product Owner can represent them each sprint.
- Appetite for structure. If the team wants Agile principles but needs defined roles and a fixed cadence, choose Scrum rather than leaving the mechanics open.
Because the approaches sit on a continuum, the answer need not be pure. The APM advises adopting techniques as appropriate to project goals and culture. A project with a regulated final stage and an uncertain design stage may justify different techniques in each.
Method choice is also separate from system design. Teams weighing how to structure the software itself can read about software architecture patterns, or about What Is Microservices Architecture? A Clear Guide To Building Scalable Apps In 2026 – Interestingdevelopment, before deciding how to organise the work around them.
Frequently asked questions
How big is a Scrum team?
Saviom describes the Scrum Team as seven to ten professionals, including the Product Owner, Scrum Master and Development Team.
Where did Agile come from?
Agile originated in software development, and Accelo notes that its principles are now used across a wide range of other work.
Does a 39% performance figure prove Agile is better?
No. Accelo cites a figure attributed to PMI that 39% of organizations that used Agile achieved higher performance rates. It describes a share of organizations, not a guarantee for any single project, so match the method to your requirements and constraints.
Is Kanban the same as Scrum?
No. Both are frameworks that apply Agile principles, but they apply them in different ways. Scrum’s distinguishing features are its fixed sprints, defined roles and review and retrospective events.
