Skip to main content

In my training classes, I often notice that students mix up iterative and incremental development (IID). The aim of this article is to provide an understanding of the relationship between incremental and iterative development.

I will start with a comparison of a waterfall and an agile approach, using the example of delivering a payment app. A corresponding mini webinar on these approaches is also included. In the second part of this article, I will position waterfall and agile in a matrix showing the intersection of incremental and iterative development, explaining all four quadrants in the matrix.

Agile Vs Waterfall: The Development Of A Payment App

The Waterfall Approach

If this example app is developed according to a traditional waterfall model, the following steps can be observed in figure 1.

diagram showing waterfall approach, with time versus value and overall usage vs total requirements

Figure 1: This diagram shows a typical waterfall lifecycle, using the example of the delivery of an app.

Project Initiation

It all starts with a project sponsor from the marketing department, who was able to free up the necessary funds for this app. It was his assumption that the app will improve client retention and the inflow of new clients. He visualized three high-level function groups.

Once the project is approved, a project manager is assigned and a project team is built. After many discussions and requirement gathering workshops, there was an agreement to deliver a payment app with 250 functionalities. All these features are recorded in an extensive and very detailed software requirements document and signed by the project sponsor and customer representative (as well as other key stakeholders).

Project Design Phase

In the next step, the project team translates the requirements into a design for the app. The architect checks the design against the design principles. He checks if all required data attributes are available in the backend system too.

We are now two months underway and the customer hasn’t seen anything working yet, only some progress reports. And these progress reports likely involve some sort of ‘watermelon’ reporting, leaving the customer with no clue as to whether the project is on track or not.

Sign up to get weekly insights, tips, and other helpful content from digital project management experts.

Sign up to get weekly insights, tips, and other helpful content from digital project management experts.

  • Hidden
  • By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at any time. Protected by reCAPTCHA; Google Privacy Policy and Terms of Service apply.
  • This field is for validation purposes and should be left unchanged.

Project Development Phase

It takes six months to develop the app and when that’s done, the customer representative is asked to deliver some people who can help with a user acceptance test. During the test, it becomes clear that several features are not working.

The project team doesn’t understand why. It’s exactly what was described in the requirements document. This leads to lots of discussions, rework, and delays, and the customers aren’t happy with the results. Furthermore, if we look at the final result, we might notice that many of the developed requirements are not or rarely used by the customer.

It could even be worse. Suppose the development of the app took 1.5 years and another bank delivers a payment app when you are halfway finished. What would you do at that moment? Would you still have a viable business case to continue and finish your own app?

Looking at figure 1, it becomes clear that with a waterfall approach, the scope and underlying quality criteria are fixed with a single delivery. All steps are performed once for the entire project and management control is focused on cost and time. Value delivery to the customer only takes place after the deployment of the complete app.

The Agile Approach

If we develop the app using an agile project management approach, we see the following pattern:

  • The development team states that they are able to deliver the first two features prioritized by the product owner in the first iteration.
  • The project team delivers every three weeks (sprint, iteration, or timebox) an increment of the product.
  • After the first deliveries or increments, we see a customer who has confidence that the project will deliver. They already have a working app, and understand that not all features are there yet, but the features that are there are working.

Looking at the latest release and the provided features, they mention a completely new feature. One that nobody had on their mind at the start of the project, but which could make the customer’s life more productive.

After every increment, the customer feedback results in new functional capabilities (which weren’t on the original list) or adjustments of potential features. The product becomes more and more mature. Every increment, the customer receives a new version and is happier.

diagram showing agile with value vs time and overall satisfaction with requirements

Figure 2: The diagram shows the agile development cycle, using the same example of the delivery of an app.

If we look at figure 2, we see a steady flow of delivery within a fixed duration and using permanent agile teams (these are fixed costs). The scope and underlying quality criteria are flexible (dynamic) with frequent small deliveries (these are the increments).

All steps intended to deliver a feature or user story are performed repeatedly (making it iterative) until the required quality is reached. Management control is focused on customer value delivery. Value delivery to the customer takes place after every deployment of an increment.

Waterfall Vs Agile: Delivery Results

If we take a closer look at the two products from both the waterfall and the agile software development approach, we see a product with 250 features and a not so happy customer and a product with only 150 features and a very happy customer (see figure 3).

diagram showing the difference in agile and waterfall methodologies

Figure 3: This diagram compares the differences in time, number of features, and customer satisfaction for waterfall and agile approaches.

And if we even look in more detail at the product delivered by the agile approach, we only see a subset of 100 features from the original list and 50 features that are new or adjusted. This is in line with some important principles of the Agile Manifesto, including:

  • Simplicity, which is the art of maximizing the amount of work not done: only 150 features instead of 250 features
  • Welcome changing requirements, even late in development: adapting to customer feedback after each iteration and increment

Agile development processes harness change for the customer’s competitive advantage (50 new or adjusted features were delivered). And as a result, the customer is very happy. The team’s highest priority is to satisfy the customer through early and continuous delivery of valuable software systems.

Mini Webinar: Waterfall Vs Agile Delivery

Here’s a brief webinar with more on the differences between waterfall and agile delivery.

Differences Between Iterative And Incremental Development

Now that I’ve covered the differences between a waterfall and an agile approach using the example of creating a payment app, I’ll position waterfall and agile in a matrix comparing iterative and incremental development.

As a last step I’ll elaborate on the minimum viable product (MVP) and the minimum marketable product (MMP) and show where these fit into the different approaches and a story map. I’ve also included a corresponding mini webinar.

Iterative And Incremental Development Matrix

As stated, I noticed that students often mix up iterative and incremental. In figure 4, you can find four quadrants as a result of a horizontal line presenting incremental or not and a crossing vertical line representing iterative or not. See this YouTube video for a very simple version of this figure.

matrix showing the difference between iterative and incremental development

Figure 4: This matrix shows different development approaches and whether team members following these approaches need to iterate and/or work in increments.

Lower Left Quadrant

In the left lower corner, we see the approach where there are no iterations and no increments. This is the waterfall approach. All activities (design, analysis, build, test, and deploy) are performed once for the entire project.

In this case, we see a single delivery of the final product based on a fixed scope. Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is to manage cost.

Lower Right Quadrant

In the lower right quadrant, we see an incremental approach without iterations. This is a staged or incremental delivery of smaller parts of the product. All activities for a given stage (design, analysis, build, test, and deploy) are performed once.

Within a given stage the scope is fixed, but the total product is based on a more dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is speed of delivery.

Upper Left Quadrant

In the left upper quadrant, we see a spiral or iterative approach without increments. This is a single delivery where the final product is created through several iterations. A good example of this approach is design thinking. In the graph you see a sequence of the activities framing, analysis, idea generation, realization, and reflection.

This sequence will be performed repeatedly or iteratively where in every iteration you get closer to the final, correct, or required product. In many cases this final product is a prototype or model. In this spiral approach we have a dynamic or flexible scope.  Customer value can only be achieved after the delivery of the final product. One of the key goals in this approach is the correctness of the solution.

Upper Right Quadrant

In the upper right quadrant, we see the agile approach that uses increments and an iterative method. Scrum is a good example of this approach.

At the end of each increment, often called a sprint or timebox, an increment of the product is delivered. This increment is the result of many iterations to develop small but correct parts, often called user stories or backlog items, of the product. The final iterative project will be delivered piece by piece.

In this agile approach we have a dynamic or flexible scope. Customer value can be achieved after every delivery of the product. One of the key goals in this approach is customer value via frequent deliveries and user feedback.


In figure 4, you can also find the acronyms MVP and MMP. MVP stands for minimum viable product and is a version of a new product or service which allows a team to collect the maximum amount of learning about customers and get validation with the least effort. The MVP for the Dropbox service was a simple movie. This means that the P in MVP could be a completely different product than what ends up being the final product.

An Example Illustrating MVP And MMP

I often use the following example of a new financial product. An enthusiastic sales manager has a great idea regarding a new financial product. He thinks that they can sell at least 100,000 of these products.

Together with some finance experts, they design the product in a couple of months. A development team is assigned, and it takes them 4 months to develop the product. In parallel, commercial brochures are developed and the product is launched with a big event.

Unfortunately, just a few people buy the product. If we follow the MVP approach, we might make the assumption that 10% of their web users are interested in this product. We would then develop an MVP to test this hypothesis.

In this case, the MVP might be a simple button on the homepage. If you click you get a screen with a message regarding this new product and the option to add your email address if you are interested. Say that less than 1% of the visitors pressed the button — the product would not be developed, and the company saved a lot of scarce resources.

If we take a closer look at figure 4, we see the potential usage of MVP’s in all quadrants. When using a waterfall approach, you could create a MVP in the first software design phase to check if there is a business justification for the project.

The same can be done in the first phase of the first increment when following a staged delivery. In some cases, the result of your design thinking approach could be a MVP. The MVP could be beneficial at the beginning of an agile approach as well.

Many people see the first product delivered at the end of your staged delivery as the MVP. This could be the case, but in most cases, this is not a MVP but a MMP. MMP or minimum marketable product is the smallest product that can bring value to your customer.

What Does Agile Delivery Look Like?

Now that it is clear that incremental models and iterative models are not the same and we understand the usage of MVP and MMP, we can explore in more detail how incremental and iterative delivery look.

You probably have seen Jeff Patton’s famous example of the Mona Lisa where the painting is created piece by piece (staged delivery). Another way to go about this is to start with the first increment in which only a rough sketch is created, and with every new iteration more details are added to the sketch, until ultimately you have the final painting (incremental and iterative or agile delivery).

In the first situation you must already have a detailed idea of the final product and in the second situation you just need a high-level outline, as changes are much easier to make. If we look at figure 5, we see a story map for a new product called ABC.

example story map for a product

Figure 5: An example story map for a specific example product.

The product owner envisioned seven features for this product. The first four features are must-haves. Feature 5 and 6 are should-haves and the last feature is a could-have. Many would call this MoSCoW prioritization (must-haves, should-haves, could-haves and won’t-haves).

Every feature in itself can be sliced down in smaller parts. In the figure you see features or user stories with must, should, and could have. A feature can be a must-have but that doesn’t mean that all the underlying user stories are must-haves too. Or a feature can be a should-have but if you implement that feature some user stories are must-haves and others are should or could haves.

To implement this ABC product, you see five increments or releases. The first one is the minimum marketable product. This MMP consists of the first two must-have user stories of feature 1, and the first must-have user stories of feature 2 and 3.

Release 2 contains the next two must-have user stories of feature 1, 2, and 3 (iterative development). Product development continues by implementing the next releases. With every release the customer value increases.

After release 5 the product owner stops implementing user stories. Feedback from the customer showed him that the ABC product is ‘fit for purpose’ and he takes the Agile manifesto’s principle of simplicity into account and stops further development.

Mini Webinar: Iterative And Incremental Development

Here’s an in-depth webinar on iterative and incremental software development.

Final Thoughts

Is your software development team clear on iterative and incremental development? How are you applying it to your agile or waterfall methodologies?

Let us know in the comments, or join our DPM membership program and discuss with other members in our exclusive forum!

Henny Portman
By Henny Portman

Henny Portman is partner of HWP Consulting. He has 40 years of experience in the project management domain. He was the thought leader within NN Group of the PMO domain and responsible for the introduction and application of the PMO methodologies (portfolio, program and project management) across Europe and Asia. He trains, coaches and directs (senior) program, project, and portfolio managers and project sponsors and built several professional (PM(O) communities. He is an accredited P3O, PRINCE2, MSP, MoP, PRINCE2 Agile, AgilePM, and AgileSHIFT trainer, and a SPC4 SAFe consultant and trainer too. He is a P3M3 trainer and assessor and PMO Value Ring Certified Consultant (PMO Global Alliance). In addition, Henny is international speaker and author of many articles and books in the PM(O) field.