Agile fixed price project and contract

Can an Agile project be fixed price? How to deliver Agile development in a fixed price contract? Besides that, how to mix Agile, Scrum and the Waterfall method?

Indeed, there are many questions on the web about how to deliver Agile in a fixed price project. As a matter a fact, there are still many software development projects that are conducted as fixed price and time contracts. If fixed price contract perfectly mixes with the Waterfall method, trying to mix fixed price contract with Agile is like mixing water and oil. Undoubtedly, whatever hard you shake, it never totally mixes.

So how to leverage Agile in fixed price projects?

Introducing the 3 type of projects compared for fixed price contract

First let’s review the 3 types of project that we will compare to highlight the different options. Their representation is based on the project steps (in blue) with the Waterfall software development steps displayed over (in pink). Indeed, all projects go through the same phases with some of them shorter. But the development steps may be sequential or iterative depending on how far the projects go with the implementation of Agile.

Waterfall project

The first type of project is the traditional Waterfall project. Truly, here, we are fully in the Waterfall project standard.

Waterfall project steps: Requirements, Design, Code, Test, Operation. Merged with generic project steps: Initiating, Planning, Executing, Monitoring and Controlling, Closing.

Agile project

Totally at the opposite is the Agile project. In this case also, we are in the market standard but this time Agile. Furthermore, the full Agile project uses Time-and-material contract. We will principally referred to the Agile framework Scrum based on iteration: sprint. Review my introduction to Scrum if you are not familiar with it.

Agile project steps: all Waterfall steps are merged and are delivered in iteration except the high level requirements before initiating. Even Operation including implementation and maintenance are delivered iteratively.

Agile augmented Waterfall

In the middle is what I will call Agile augmented Waterfall. For sure, it is still a Waterfall project but leveraging the power of Agile within the limitations of the Waterfall. Yet, some of these limitations adapt to provide a little bit of flexibility and enable part of agility.

Agile augmented Waterfall project steps: all Waterfall steps are merged and are delivered in iteration except the high level requirements before initiating and the maintenance part of operation step after closing.

Water-scrum-fall project

Nevertheless, it is different from the market term “water-scrum-fall“. You can find other synonyms for like “water scrum fall”, “waterscrum” or “scrumfall”. In fact, in “waterscrumfall”, at least the requirements, part of the testing phases (acceptance) and implementation remain strictly sequential and with the same level of detail than in the traditional Waterfall project. But, even if Agile empowers only design, development phases and most of test, it is still a progress in comparison to the standard Waterfall approach.

Agile augmented Waterfall is not Agile!

Note that if Agile augmented Waterfall allows more flexibility in comparison to Waterfall, it is not Agile. But I is not all bad either. If you do not have the choice and have to comply with a strict contracting structure, it is already a start to leverage some of Agile.

GAO Agile Assessment Guide

For the Agile augmented Waterfall, we will leverage the GAO Agile Assessment Guide as main reference source, in addition to my personal experience. Indeed, the GAO is “watchdog” of the US government congress. Therefore, one on its mission is to audit agency operations to enforce that they spend efficiently and effectively federal funds. And the federal government of the USA invests at least $90 billion annually on Information Technology. As a consequence, the GAO issued a guide to make sure that agencies properly leverage Agile best practices especially in the context of fixed price project. Really, it is the best source I know on how to improve Waterfall projects with Agile.

Prerequisites to deliver Agile in a fixed price project

The first step, is of course, to have all stakeholders know what is Agile. Therefore all teams, business stakeholders, in particular POs and PMO should be trained to Agile. Furthermore, for contractors, the best way to address the topic is by requiring a certification for all staff, one of the main market framework like Scrum.

Then the project stakeholders should select the type of contract to deliver the Agile project: either in full Agile in a time-and-material contract or as an Agile augmented Waterfall project in a fixed price contract. They should consider characteristics of the project notably the constraints, the risks and the level of uncertainty to make their choice.

Initiating Agile fixed price project

Initiating Agile fixed price project: Waterfall is strictly on what, Agile on emerging what and why, Agile augmented Waterfall on high level what and why (Epic or Feature level).



In Waterfall, the scope is on the “what” and expectations are fully detailed since the beginning.


On the contrary, a time-and-material Agile project has an emerging scope covering “what” and with the support of “why” defined at high level and being refined as the project goes.

Agile augmented Waterfall

In the middle is the Agile augmented Waterfall project. Like traditional Waterfall, there is a full description of the scope, the “what” but it is at a higher level either Epic (big topics of the project) or Feature (macro functionalities). And it includes the “why” for each to provide a direction. Detail is discovered as the project goes.



Waterfall project has a Statement of Work. In other words, it is the detail of all the work to be done. Undoubtedly, all the requirements are to be captured in detail before starting the project.


At the opposite, in the Agile time-and-material project, the business sets its ambition based on how much it is ready to invest on the opportunity or better how much it is ready to bet. This investment is a partial investment to have a better understanding on the potential of the opportunity. The first step is a Proof of Concept (POC) that will give a first validation of the outcomes and confirm the velocity of the contracted teams.

Agile augmented Waterfall

In between, the Agile augmented Waterfall project comes with a Statement of Objectives that is:

  • A high level description of work (Epic or Feature level),
  • A collection of overall objectives as a vision, a purpose,
  • Acceptance criteria like expected performance standards and operating constraints,
  • Committed people and related organization to achieve desired outcomes.

Truly, the measure is on the outcomes not on specific tasks that contractors should perform.

The Agile augmented Waterfall project tries to find a balance between making sure that an initial high level scope is delivered and enabling:

  • Continuous discovery of requirements,
  • Flexibility with multiple options,
  • Delivery of value iteratively.


The backlog is the key artifact supporting these objectives. Actually, it plays the role of the Requirements Traceability Matrix with a strict connection of emerging User Stories to Feature and Epics. Definitively, this makes it possible to prevent scope creep and to enforce high level scope defined at the beginning of the project. And at the same time, it allows flexibility as User Stories emerge while the project goes.

The Waterfall hierarchy of works may become in Agile augmented Waterfall project as follows:

  • Epic/Capability may stand for Control account,
  • Feature may stand for Work package,
  • User Story may stand for Quantifiable back-up data.

Planning Agile fixed price project

Planning Agile fixed price project: Waterfall has a strict planning with detailed estimation and full contingency, Agile still has a roadmap but living, with high level estimation and no contingency, Agile augmented Waterfall has a reference planning at high level (Epic or Feature level) with estimation at this level and contingency but lighter.



Waterfall project traditionally comes with milestones.


On the contrary, Agile is time-boxed: the end of each iteration is an opportunity to deliver to production. If there is an important deadline to meet, then additional refinement of the backlog will clarify if the scope can be delivered within the time frame. Mandatory and arbitrable Features will be clearly identified to confirm that it will be possible to deliver the minimum expected before the deadline.

Agile augmented Waterfall

In the middle, the Agile augmented Waterfall project still has the same milestones as the Waterfall project. But these milestones fully leveraged the Agile cadence.

The Agile augmented Waterfall project leverages modular contracting and adapt technical review to build the roadmap.

Modular contracting

Modular contracting is the idea of designing the project, therefore the contract, in delivery batches. Indeed, all delivery batches are independent and consist of the delivery of an increment to production. Furthermore, there should be no need to commit when contracting a delivery batch, to contract the others with the same vendor. As a consequence, when deliverables are properly tested and documented, the project avoids vendor lock-in.

Truly, this is enabled by the state of art of Agile practices as described in Lean Startup where delivery and early exploration of opportunities are delivered with Minimum Viable Product (MVP). All these MVPs onboard the minimum Features to be relevant to the market but also to learn and confirm hypotheses.

Technical Review

Technical Reviews, in Waterfall project, are a control gate on quality and risks to move from one sequential phase to the next. With the delivery of fully operational Features by the flow, Agile allows early validation and quality and risk management. As a result, problems are discovered and fixed early before they become to big. Therefore, Technical review evolves to become a kind of retrospective on the achievements of the past time period and to take a step back.



Waterfall project has a detailed planning or roadmap. In a point of fact, it is a reference roadmap, the baseline from which to measure schedule deviation to the initial plan. Definitively, it is not supposed to change and if so, changes are validated by all the project stakeholders.


Agile comes also with a roadmap. But it is to support the vision where the project goes. It is not a reference or a plan mandatory to follow. In fact, it is living and it evolves with the project.

Agile augmented Waterfall

In between, the Agile augmented Waterfall has a planning or roadmap, but at a higher level (Epic or Feature level) to enable flexibility at User Story level. Similarly to Waterfall project, it has a critical path, but at Epic or Feature level. It integrates a reasonable float or slack at this level to secure this critical path, especially if non-agile teams contribute. In other words, in this approach, the roadmap is also a baseline to measure schedule variances.

Nevertheless, the roadmap is more open to change even if like for the Waterfall, all stakeholders validate the updates. At last, teams should be fully aware of the dependencies, so they can take them into account to self-organize their work.

Estimate work effort and contingency


Waterfall project, based on fully detailed scope, totally estimates the work effort. Without a doubt, Waterfall project dedicates a lot of time and workload to estimation. In addition, the project computes a contingency budget.


Instead, as we have seen before, Agile proposes a different approach where the estimation of the project starts with how much the business is ready to bet. Nevertheless, a high level estimation at macro level (Epic or Feature) may help with a bottom-up confirmation of the sizing. Still, the real confirmation comes with the early phases and outcomes of the project.

Agile augmented Waterfall

Similarly to Waterfall, the Agile augmented Waterfall project performs estimation but at higher level (Epic or Feature). In addition, there is still a need for a contingency budget. Usually, as there are other means of control and early validation with “by the flow” delivery, the contingency is lower than traditional Waterfall project.

Management of contributions and risks

Note that for all type of project, a special concern is required to secure contributions outside the project teams in time and capacity. Furthermore, risk management should remain a key practice in all projects. Actually, in Agile, backlog is prioritized regarding value and risk management.

Executing Agile fixed price project

Executing and controlling Agile fixed price project: Waterfall project collaboration between business and IT is at the beginning and the end of the project, Agile and Agile augmented Waterfall projects have collaboration all long. Data and documentation are limited to minimum to enable opt-out and for knowledge management in Agile and Agile augmented Waterfall projects.

Collaboration between business and IT

Collaboration over the software development steps are directly connected to the type of project and how deeply Agile is implemented.


First, in Waterfall project, with full sequential steps, collaboration is only during requirements collection and design, then after the build of the solution, during testing and implementing (training).


Second, in Agile, all steps happen at the same time even if there may be an early step of collection of high level requirements to decide to trigger the project. Collaboration is intensive during all the phases.

Agile augmented Waterfall

At last, in Agile augmented Waterfall project, only the collection of high level requirements is a sequential phase. Indeed, all the other steps happen at the same time even. Therefore collaboration is intensive during all the phases.

Documentation and Data


In Waterfall project, the Statement of Work fully describes the expected documentation and data. Actually, many of them are by products to support sequential phases.


On the contrary in Agile, the development team limits the documentation to what last, not by products. For instance, there are still specification, in particular when business is complex, but they should be designed to be the technical documentation of the solution. In other word, Agile builds the minimum level of documentation to allow opt-out and for knowledge management. The team and the software generate Data and the Agile metrics iteration after iteration.

Agile augmented Waterfall

In between, the Agile augmented Waterfall project follows here the Agile approach. Documentation is just enough to allow opt-out and for knowledge management. Regarding Data, traditional contract’s data requirement is adapted to align and leverage Agile metrics and related process and artifacts. In addition, there are many moments throughout the Agile development life cycle where project can capture data about the quality.

Monitoring and controlling Agile fixed price project

Monitoring and Controlling Agile fixed price project: contrary to Agile, all changes of scope are negotiated but at Epic or Feature level for Waterfall and Agile augmented Waterfall. The backlog in Agile augmented Waterfall enforces a strict hierarchy between User Story, Feature and Epic to be used as Requirements Traceability Matrix. At last, Agile augmented Waterfall mixes Waterfall metrics at Epic or Feature level with Agile metrics for iteration, sprint.


If Waterfall project and Agile, either as project or not, have their usually metrics, Agile augmented Waterfall has a mix of metrics coming from both approaches:

  • Project Management with metrics coming from:
    • Waterfall, like earn and burn on delivery of Epics or Feature, and deviance from budget and schedule,
    • Agile velocity based on User Stories and at level of iteration, at sprint level, like burn down,
  • Technical management of quality for instance on the technical debt and the quality of code,
  • Agile maturity and how well the project masters Agile.

Requirements Traceability Matrix

As reviewed before, Waterfall and Agile augmented Waterfall projects enforce initial scope all project long. But the difference is that for the second, the requirement are managed at a higher level (Epic or Feature).

In addition, in Agile augmented Waterfall, this is the backlog that plays the role of Requirements Traceability Matrix. As a consequence, the backlog needs to strictly enforce the hierarchy between User Story, Feature and Epic. This is the prerequisite to prevent scope creep.

Scope change


In Waterfall project, each change triggers a change request and is validated by the project stakeholders. It is financed either by scope arbitration or extra budget.


On the contrary, in Agile, all changes are welcome except during the iteration, the sprint. The is no need to enforce the scope. But the Product Owner has the responsibility to maximize value at each sprint.

Agile augmented Waterfall

Similarly to Waterfall project, Agile augmented Waterfall, closely manages the scope’s changes and enforces delivery within scope, but at a higher level (Epic or Feature). On the contrary, All changes and emerging needs are welcome at the level of User Story. They should be, like in pure Agile, strictly prioritized to make sure that if an Epic or a Feature runs out of budget, arbitrated User Stories are optional.

Closing Agile fixed price project

There is not much to say here as the same closing step is relevant whatever the type of project. Indeed, it is about having a final project review to take a step back on the whole project and capture learning. In Agile, the closing will happen with the switch from project to product mode as the build of new features will keep going until the end of the life of the product.

Reassessing to type of your Agile fixed price project

If Agile augmented Waterfall makes it possible to bring some Agile to a project, it remains a compromise with average benefits. Once the project has started and is in a cruse mode, with the contractor delivering the expected value in a stable velocity, it is a good idea to go further. Thanks to the POs fully playing their role and maximizing value iteration after iteration, consider for the next batch of delivery, the next MVP, to switch to time-and-material, so the POs will have full ability to adapt if need be.

What’s next? Learn more about Agile at Scale

Check my other posts about Agile at Scale:

Do you want to learn more about Agile fixed price project? Here are some valuable references

Traditional project

GAO, the main inspiration source of this post

Scrum alliance and PMI collaboration, to have an idea what the best of classes propose on the topic

Some web posts on Agile fixed price project, to have an idea on what is on the web

Some web posts on scrum-water-fall as anti-pattern to Agile

Leave a Comment

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

3 × four =

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top