Waterfall vs V-Model vs Scrum vs Kanban

Waterfall vs V-Model vs Scrum vs Kanban

Waterfall, V-Model, Scrum, and Kanban are popular project management approaches and approaches to work and product development.

The classic project management and Agile project management approaches include different methods of work. Reference: “Agile vs Waterfall: The Difference Between Methodologies”, 2020 BUSINESSPAD.ORG, author: Samantha Rhine, In the article, we will explain all of them in detail.

Waterfall versus V-Model versus Scrum versus Kanban

I hope that I will be able to give you the clearest and most comprehensive information about “Waterfall”, “V-Model” and “Agile”.

As the name of the process suggests, this is an approach in which project-related activities are divided into linearly successive stages (phases). Reference: “Waterfall and Incremental model in project management”, (2019 Wikipedia Lab), This means that only after the complete completion of the first stage, you can move on to the next stage. This means that each stage depends on the previous and specific tasks. Unfortunately, this approach is not very “flexible” and in cases where a change related to the product is required, a lot of difficulties are created in its implementation. The photo below clearly shows what “Waterfall” really is. Reference: “Agile vs Waterfall management methodology”,



In this phase of the project, a “Product Requirements Documentation” is created. This is the document that contains all the system, functional and non-functional requirements for the product.

  • What it will look like
  • What features will it have?
  • How exactly will it work, etc?

It is important to note that the creation of all this documentation and the “cleaning” of incorrect or mutually exclusive requirements is a very laborious process involving multiple meetings between our system engineers and those of the client. It also requires extremely good system engineers to detect a specification error at this stage. Reference: “Waterfall or Agile? What methodology to choose for your project?”,


In the “Design” phase, the “architecture” of the product is made. In it, engineers from different specialties (SW, HW, Mechanics, etc.), based on the “Requirement Documentation”, decide how all the requirements can be met and become a working product.
This process is time-consuming because, like any modern product, it is too complex. Reference: “Agile vs Waterfall Project Management”,


This process begins after the project architecture is done. This is the phase in which the actual creation of each element of the product begins (SW, HW, Mechanics, etc.)

At this stage of the process, it is clear if in the previous 2 stages an error was made in the creation of PRD or the construction of the Product Design.


At this stage, tests are performed, or in other words, to check whether the product works as described in the PRD. This is also the stage in which the mistakes made in the previous 3 stages are most clearly evident. Removing any bugs found at this stage can be very costly for the company.


The Maintenance stage is the moment when the product is ready and put into operation. It eliminates problems found during the operation.


The V-model is an “extension” of the “Waterfall”. Reference: “Agile, Scrum and Waterfall project management”, On the left side of the V is the processes for defining the project (Concept of Operation, Requirements and Architecture, Detailed Design). On the right side are the processes related to integration and testing. (Integration, Test and Verification, System Verification and Validation, Operation and Maintenance). For each process development phase (left side) there is a corresponding validation stage on the right. Reference:

Project Definition
Requirement analysis

This is the first step in the process. It collects and analyzes all the wishes of the user (users), or in other words – describes how the “ideal” project would work. Reference: “Project Analysis”,, 2019, At this stage, it is not yet discussed how the software will be made or how exactly it will work. All these requirements are recorded in a document called the “Customer Specification”. (User requirements document).

It usually contains the following information about the “product”:
System’s Functional interfaces, performance, date, security, etc. Once the document is created, it is reviewed by the users (client) and used in the next stage of the process. (System design). The customer specification also describes User Acceptance tests.

System design

In this phase, the system engineers analyze the business purpose of the project using the “Customer Specification”. It is also clarified what are the possibilities for these customer requirements to be realized. When a problem is identified with any of the customer’s requirements, a “defect or ticket” is created, where the problems are tracked and cleared from the customer’s specification. Reference: “Comparison of Agile, Scrum and Waterfall project management”,

A document called “Software specification” is being prepared, which contains the basics of the project, the structure of the project, whole diagrams, schemes, etc.

Architecture design

Software architecture can be described as “high-level design”. When creating the SW architecture, a list of modules is made, a description of the functionalities of each module, connections, and dependencies between the different modules, diagrams, technological details, etc.

Module design

“Low-level design”. In this phase, the system is broken down into small parts or modules, which are described in detail so that the programmer can understand how the module will work and start writing the program code directly. This document contains:
Interfaces and API references, Error messages, all input and output “variables” for the respective module, as well as a description of Unit tests.

Project Test and Integration (Validation Phases)

In the V-model, each step of the “Verification” (left side of the V) phase has a corresponding phase in the “Validation” (right side of the V) phase.

Unit testing

The unit test is determined during the design phase. UTs are executed to identify and eliminate all defects at the code level or unit level. “Unit” is the smallest possible part that can exist on its own. The UT aims to ensure that each Unit works correctly when isolated from the rest of the code.

Integration testing

Integration tests are determined during the Architecture Design phase. The purpose of these tests is to make sure that the modules can work with each other without any defects.

System testing

System tests are determined during the System Design phase. Unlike UN and IT, System tests are created by the client (sponsor) of the project and aim to ensure that its expectations are met and the code works the way the client expects. STs check that functional and non-functional requirements are met. The following tests are also performed: Load, Performance, Stress, Regression test, and others.

User acceptance testing

UAT is developed during the Requirement Analysis phase. These tests are determined by the clients (guarantors) of the project. They are performed in a “real” environment and realistic data is used. They aim to check whether the project is ready for commissioning.


A flexible method of software development, invented by a group of software developers, who realized that creating software is a dynamic process and often requires changes even at the last minute. This system allows the client to easily receive the current status of the project and return feedback to the contractor.
Scrum and Kanban are the two main Agile methods. Reference: “Waterfall vs Agile Project Management”,


Roles (positions)

Product Owner (PO) – a position responsible for setting the product direction. It is a representative of the end-user or the customer. It is the responsibility of the Product Owner to ensure that the correct features are entered in the Product backlog in the form of a User Story. It also determines the priority of each User Story.

Scrum Master (SM) – the main goal of this position is to ensure compliance with Agile practices, the smooth progress of the project, as well as to ensure that each team member has everything necessary to do their job. Organizes meetings, monitors and controls the progress and release planning.

Development Team (DT) – most often consists of programmers and test engineers. They aim to develop the product.

Customer – Customer or assignor of the product.


User Stories (US) – High-level description of functionality that the client wants to have in the finished product. Created by Product Owner. Reference: “User Stories Real Example. How to create user stories. Example of Acceptance Criteria and Definitions of Done”,

Product backlog (wish list) – a list of all the necessary user stories for the full development of a product.

Release (Iteration) backlog – a list of all necessary user stories for the full elaboration of the current release (iteration).

Sprint – 2 consecutive weeks

Sprint Planning Meeting – a meeting at the beginning of each sprint, which prioritizes all product backlog items that must be completed by the end of the current sprint.

Sprint backlog – a list of all US that must be done for a particular sprint.

Sprint Review – a meeting that takes place after the end of each sprint and aims to make a presentation of the achieved goals to customers or stakeholders.

Sprint Retrospective – a meeting that takes place after the end of each sprint and aims to answer the following questions:

  • What went well?
  • What went wrong?
  • What can we improve?

Daily Scrum – a daily meeting lasting 15 minutes, in which all participants stand up and share in the shortest possible time what they have done since the previous meeting and what they plan to do until the next meeting, and whether there is something that blocks their work.

Scrum board – a board that monitors the progress and status of each user story.

The Product Owner aims to collect and describe in the form of a User Story all the customer’s wishes for a given iteration. Once this is done the User Story is placed in the Release backlog. The development team receives the Release backlog and estimates, prioritizes and plans each

User Story. Once the User Stories are placed in the Sprint Backlog, work begins on each story. Every day, the Scrum Master organizes Daily Scrum meetings, in which each member of the team must provide information on what he has done since the previous meeting and what he plans to do until the next daily meeting. The progress of the work and each story is monitored by the Scrum Board. After completing the sprint, the finished product is provided to the customer, thus, the customer can check whether the product meets his expectations and requirements. All services that are not completed in the specified Sprint are returned to the Release backlog. Each sprint ends with 2 rituals: Sprint Review and Sprint



Roles (positions)

Product Owner (PO) – a position responsible for setting the product direction. He is a representative of the end-user or customer. It is the responsibility of the Product Owner’s role to make sure that the correct features are entered in the Product backlog in the form of a User Story. It also determines the priority of each User Story.

Agile Coach – the main goal of this position is to ensure compliance with Agile practices, the smooth progress of the project, as well as to ensure that each member of the team has everything necessary to do their job. Organizes meetings, monitors and monitors the progress and release of the plan.

Development Team (DT) – most often consists of programmers and test engineers. They aim to develop the product.

Customer – Customer or assignor of the product.

Kanban board – a board that monitors the progress and status of each US.

The Kanban approach does not have Sprint or Sprint Backlog. The Continues progress method is used. How many product backlog items can be made is determined by the capacity of the team. The main goal is not to overload the teams. The Kanban board has 3 columns: Build, Test, and Done.

When a User Story is ready, it is moved from Build to Test. After successful testing of the story, it enters the Done column and is passed to the client. When a column is empty or contains less storage than its capacity, it means that it can take on a new User Story.


“Waterfall Project Management or Agile Methodologies: What to Choose?” 2021,

“Waterfall and Agile project management”, 2021,

“Agile methodologies” by Liam James, 2020,

Waterfall and Agile project management

The methodology of this model, which is also known as the sequential linear life cycle model. The waterfall model follows in sequential order, so the project development team only moves on to the next phase…

Agile Project Management

Agile Project Management includes different subjects and many Agile and Scrum practices as well, but we will discuss here several major topics…


I sincerely hope that through my brief explanations I have been able to give you the most important information about the various methods of software development.

There is no “perfect” method of development in the real world. Each method has drawbacks. The question is by what criteria we evaluate them. Recent years have been extremely dynamic and often clients want to change, add or remove a project functionality.

In case the project is developed through “Waterfall” or “V-model”, the implementation of these changes would endanger the very successful completion of the project on time or may lead to large financial losses.

It is for these reasons that the Agile method is preferred for software project development. Because of its flexibility, the changes desired by the customer can be relatively easily implemented at an affordable price, and in the end, this is what our customers are looking for.

One reply on “Waterfall vs V-Model vs Scrum vs Kanban”

Both Agile and Waterfall are ways to organize project development work. They can also be defined as ways of managing projects or specific approaches. These are the two most basic project development methodologies.

I would say that both are applicable, but both have their strengths and weaknesses.

Waterfall methodology, I consider a consistent approach to development. It separates the whole process into definite stages, each of which is simultaneously connected with the next, but there is also a certain strict sequence of action.

This project development methodology, on the one hand, offers a clear agreement between the client and the service provider from the very beginning of the project life cycle.

This is a prerequisite for faster work since the project is described in full in advance between the customer and the supplier-contract are all the requirements of the customer. In my opinion, however, this can be both a positive side and a negative side, because the coordination of the requirements and views of the clients in connection with the vision and development of the project is not always clean and clear. Not every client can coordinate the vision of the desired project with the needs for its development.

On the one hand, this can be a very efficient way of working, which leads to faster implementation of the project, but also customer dissatisfaction with the delivered product, because they only show a vision and can not see what will be the final product until the very end.

On the other hand, the methodology – Agile, divides the work into stages that have a certain deadline for implementation with clearly defined goals. In case there is a delay in any of the stages, the work is prioritized and reorganized as the ultimate goal is the delivered product and information retrieval based on process analysis for future projects.

One of the main differences with the first approach is that customers have a periodic review of the process, this allows changes in the work process to meet its needs. In my opinion, this gives the customer more peace of mind for the development of his product. Of course, this can be seen as a negative side of this method, because it can lead to delays in the work of too frequent changes in customer requirements and new proposals and desires.

This can lead to the inclusion of new stages in the project and a complete reorganization of the work.

In connection with our work, I do not think it is necessary to adhere strictly to a specific method of project management. I believe that customer participation at the beginning of the process is mandatory, but it is also necessary to periodically coordinate the product.

Leave a Reply

Your email address will not be published. Required fields are marked *