What Is the Waterfall Method?
Waterfall is a long-term product development method characterized by linear sequential phases for planning, building, and delivering new features or products. Requirements are meticulously defined upfront and implemented sequentially in the following phases: conception, initiation, analysis, design, construction, testing, production/implementation, and maintenance. Each phase must be completed before the next one begins.
Basic steps of the waterfall method:
Step 1 | Gather and document requirements |
Step 2 | Design the new feature or product |
Step 3 | Code and unit test |
Step 4 | Perform system testing |
Step 5 | Perform user acceptance testing |
Step 6 | Fix any issues |
Step 7 | Deliver the finished feature or product |
How Does Waterfall Differ from Agile?
Waterfall is a more traditional, sequence-based methodology. In contrast, agile is an iterative product development methodology in which teams work in brief, incremental sprints and frequently regroup to review the work and make changes.
Here are a few of the key differences between waterfall and agile:
The agile methodology, far more flexible, encourages frequent feedback and the ability to quickly switch focus and priority. With the waterfall method, product managers set rigid plans in discrete phases for development teams to execute. In other words, once the work for a stage has been completed in a waterfall environment, there’s no turning back: Development must move on to the next stage.
Pros and Cons of Waterfall
While the waterfall model may be well-suited for projects with fixed requirements and scope, it’s not a good fit for other types of projects.
Here are some of the advantages of using waterfall:
- A strong emphasis on meticulous documentation (e.g., requirements, design documents, and source code) helps preserve product knowledge as team members come and go.
- The structured approach is easily understood and has identifiable milestones.
- Time spent earlier in the production cycle to find and fix problems can reduce costs later on.
- Early planning and agreement about requirements can help manage customer expectations more effectively (e.g., size, cost, timeline, etc.).
- Stakeholders can see tangible deliverables and progress at every stage.
Of course, there are drawbacks to the waterfall method as well. Here are a few notable ones:
- The rigidity of the waterfall method allows for little to no flexibility for changes as customer needs or requirements evolve.
- Undefined or vague requirements can lead to increased costs later on (e.g., redesign, redevelopment, and retesting).
- Customer dissatisfaction can easily take root and grow when the final feature or product doesn’t align with their ever-evolving customer needs or requirements.
- Since the feedback and testing phases occur later in the development cycle, the risk of newly discovered constraints, requirements, or problems severely impacts development and costs.
When Should You Use Waterfall?
Recent research from the Project Management Institute indicates that roughly half of all organizations use waterfall. Some organizations, however, like the U.S. Department of Defense, have entirely moved away from waterfall-type methodologies.
While Waterfall is not an ideal product dev method for complex projects or projects with requirements that are likely to change, it can be a reasonable method for short-term projects with clearly defined, fixed requirements.
According to Product Manager HQ:
“Ideally, your team should be using the waterfall methodology if there is a very clear picture of what the final product will be and if you know that your users won’t have changing needs once the project has begun.”
Here are key considerations for choosing the waterfall method:
Clear, fixed requirements | ✔ |
Stable product definition | ✔ |
Straightforward technology | ✔ |
No ambiguous requirements | ✔ |
Freely available resources and requisite expertise | ✔ |
Short project length | ✔ |
Still trying to choose between waterfall and agile? Read this.
Related terms: Agile, Agile Manifesto, Agile Framework, Agile Transformation, Product Requirements Document.