Agile Contracts

Few months back, I wrote a blog article about ‘Fixed Price Agile contracts’. I could not go back and finish the subsequent parts at that time, and I got many requests for Part II. Post that, I spent quite a few days researching and organizing a webinar on ‘Agile Contracts’ which prompts me to write this new blog article on ‘Agile Contracts’. Fixed price is more or less implied here, as we all know the contracting clauses come into play more strongly in a fixed price scenario as compared to Time & Material. BTW, we had overwhelming response to the webinar from all parts of the world, so thanks everyone ! The webinar slides are going viral on Slideshare…

Here I have attempted to take those concepts and outline Agile contracts end to end. And as usual, we refine as we go 🙂 I have a feeling this write-up is going to be a very long one!

Agile Contracts

Agile Contracts is a ‘hot topic’ these days and it is not a surprise. Agile has evolved from a bunch of interesting concepts to serious mainstream strategic goal. The Agility needs of each organization is different (but that is another topic in itself about which I will write soon).

In early days, Agile used to be the method for product companies and volatile businesses. Now even US and UK government have prescribed guidelines for Agile execution and vendors are asked to prove their agile capabilities in the pre-qualifying round. These new developments bring forth many challenges to service providers, especially the ones which have been catering to very large projects with traditional contracting clauses. The other group that need help are the Contract Administrators, Procurement Managers and client-side Project Managers

I have seen some good posts out there explaining 10 different ways to do agile contracts. But unfortunately, what I found missing was specifics around structuring the clauses, terms and conditions. I could not use these posts and convert my traditional contract into an agile one in a matter of few hours. And this is exactly what I am attempting to do here. Hopefully, the guidelines given here are good enough for you to look at your contracts and change the clauses. In case you need any help with it, you know who to ask 😉


Now, if you are coming from an innovative product company, internet company, or any such businesses where contracting between supplier and customer is not deemed necessary, or very light and loose contracts are the norm, please do not attack me for this post, as this is meant for formal businesses and especially large projects where very formal contracts are expected between both the parties.

How contracts have been done traditionally

Traditional projects (waterfall) were based on different principles as compared to agile.

Usually when people say fixed price, they mean fixing the price, time, and the scope. To be able to fix the scope, detailed, stable and accurate requirements is a must. In traditional fixed price projects, the language of the contract was  the assumptions on which projects are executed:

Upfront requirement gathering

In traditional fixed price, once the requirements are brought in, they are signed-off and any deviation from the baseline is considered as a change request irrespective of the priorities or business value it can bring. The contract will bring forth this aspect in its language by enforcing each and every detail of the project’s requirement and design is thought about up-front.

Late business value

There is no business value “seen” till the very end of the project. Hence from the client’s perspective, the contract guards against delays and incomplete deliverables and introduces penalty clauses whereas from the vendor perspective, the contract guards against pull outs and non payment.

Accurate estimates and timeline commitments

The non-agile methods expects that people would be able to ascertain the exact number of hours/ cost to complete the project milestones and a golden date that the software can be released. The contracts are thus built in a way to hold the vendor to these commitments  in terms of payment and legalities.

Why do we go for Agile Contracts?

If you are trying to get into an agile contract because your client is asking, or because the management is asking, or your competitors are doing it, please think twice. These are ‘wrong’ reasons to go for agile contracts. If the below given reasons are why you are doing it, you are in the right track:

  • To ensure early business value (ROI)
  • Secure the time and the cost
  • Lower the delivery risk

These factors need to be built into the contracts and the contract should protect these original intents.

agile contracts

When we compare traditional and agile projects, almost all the below aspects of project management is done differently.

  • SDLC
  • Roles and Responsibilities
  • Scope management
  • Schedule management
  • Milestones
  • Deliverables
  • Payment terms
  • Change management process
  • Project control & status

Almost every one of these above mentioned aspects is different in Agile as compared to traditional, and the contract obviously should take care of these differences.

We are talking about assuring great results and a mutual win-win while we are trying to move from a scenario like this:


To a scenario like this:


When the whole way of working, deliverables, expectations etc change, how do we still have a tight contract that both the parties can hold on to?

The case of the ‘Inverted traingle’ : solve this, and you solve the enigma of agile contracts!


We all know the traditional ‘triple constraints’. Traditionally, we used to ‘freeze’ the scope and estimate effort, cost and schedule.  In agile, the pyramid is ‘inverted’. i.e, we may or may not have all the scope defined, yet we have to estimate the time and cost.

In agile context, we have a fair idea about how much time we want to dedicate to the project and how much money we want to expend. But unlike traditional projects, it may not be possible to have all the scope defined upfont. Yet, customers will demand agile delivery and would want to get into Fixed price agile contracts.
How do we tackle this scenario?

Scope in Agile

In the Agile context, the time you want to invest is known, the  budget you want to expend is also known.But what about the ‘scope’ in Agile?

Definition of Scope in Agile

Scope in Agile is  equivalent to delivered ‘business value’ as opposed to WBS in traditional projects. The requirements are depicted as epics, features or stories depending on the level of granularity. Some examples of scope in Agile context:

  • Sales forecast report
  • Screen to capture employee details
  • Register a retail customer
  • Make an online payment transaction

Some examples of what is NOT scope in Agile:

  • Project status reports
  • Risk register
  • Earned value report
  • Task assignment register

Project management activities are not considered as deliverables though will have to be priced and charged in the contract.

Measuring Scope in Agile

Scope in agile is measured as ‘Size Units’. There are many conventions to measure size; story point measurement is a popular method. Examples of size units are:
  • Story points
  • Feature points
  • Epic points etc.
Size is nothing but the relative measure of the complexity of the requirement. Size is not equal to the effort.  Size of a requirement is measured in comparison with the other requirements in the same project. Size is measured using mutually agreed parameters between the supplier and the client.
A good ‘sizing framework’ with pre-agreed parameters is recommended at the time of contracting to ensure that the client and the supplier are on the same page while measuring the complexity of the scope.
For more details on sizing and sizing frameworks, please refer to my blog on Software sizing or the whitepaper on ‘software sizing’  (Beta version of a  sizing framework and estimation tool is in the making. Let me know if you would like to try it out)

The inherent conflict between Agile & fixed price

Agile embraces changing scope whereas a fixed price expects that the scope is clear and unchanging! The challenge?The customer still wants to know how much it costs, when it will be delivered, i.e. they still want a ‘fixed price’ for unclear or possibly varying  scope.
How do we arrive at fixed time and cost when requirements are not clear and the scope is not fixed?

Clarity and stability of requirements – A deciding factor for building fixed price contracts

These challenges bring us down to the typical scenarios that could determine what kind of contract one should go in for:
Agile contracts

The three zones above depict:

Zone 1: Requirements are available and stable, so it is the most easiest of the Agile contracts

Zone 2: Requirements are available partially, and there is a probability of requirements change

Zone 3: Requirements are not at all available, so we have to look at innovative approach to structure the fixed price contracts

As we go forward, we will explore how to structure contracts for all these scenarios.

Scenario 1: The requirements are very clear and stable

In this context, it is quite simple to structure an Agile fixed price contract.

Agile contracts


Single contract with a single statement of work (SOW)
Contract Type: fixed price

Execution steps:

-Size the requirements using the sizing framework
-Derive the effort and the cost from the size
-Agree on the delivery timeline
-Deliver iteratively in multiple sprints
-Frequent demos at the end of every sprint
-Frequent releases after every few sprints

In Fixed price contracts, regardless of effort or the time, the cost is fixed. The cost/ effort can increase due to two main reasons:

1.Scope increases, and the changes are uncontrolled and free.
2.Non-delivery and delay due to skill deficiency or any other supplier induced reasons

In the above case, if the project is delayed by two sprints, the supplier absorbs the additional cost (unless it is due to scope change and the relevant conditions are taken care in the contract).

In projects where the requirements are not clear and yet there us a need to build an estimate and commit on a timeline, the following is suggested for circumventing this ‘scope clarity issue’ and minimizing the risk.

Scenario 2: Partial requirements or only high level view available

In this context it is better to divide the project logically into two blocks.


One contract; Two SOWs
Contract Type : Fixed price + fixed price

First SOW (Fixed price)

-Execute the available scope in few sprints
-In parallel, size the remaining at high level

Second SOW (Fixed price)

-Execute the remaining scope by following the execution steps in the previous scenario

In this case, it is advisable to build in a variance of +/- 15% into the estimations.

agile contracts

The most challenging scenario is when there are no  requirements  at all. Sometimes  we are faced with situations where we have an evolutionary approach to the product which is in making. Yet, in this case also, structuring Agile contract is still possible.

Scenario 3:  No requirements; only objectives & goals available

In this context also, the project is split into two logical blocks.


One contract; Two SOWs
Contract Type: T&M with cap + fixed price

First SOW (Time & Material with Cap)

-Execute the Proof of concept/ prototype
-In parallel,  size the remaining at high level

 Second SOW (Fixed price)

-Execute the remaining scope by following the execution steps as in the previous scenarios

The first contract has a cap built into it so that if the prototype is not found to be feasible, it can be a decision point whether to move ahead into the next phase or not.  This is a risk mitigation strategy.  In this case, it is advisable to build in a variance of +/- 25% into the estimations as the level of risk is comparatively higher.


agile contracts

Let us look at how this type of a contract creates a win-win for both Customer and the Supplier.

Wins for the Customer

– If the project is deemed to be risky due to lack of requirement clarity, technical clarity, or any other unknowns, having a prototype phase helps to gain more clarity and to evaluate the feasibility of the overall project.

– The Customer benefits by having a cap on the  T&M phase thereby reducing the risk of financial investment.
– Gives the Customer confidence that the commitment from the supplier is realistic after the scoping phase.
– Fixed price of the execution phase gives the perception of security to the Customer. The budget is controlled. An informed fixed price reduces the risk of overruns on effort and schedule for the vendor.
– The concept of story sizing allows for “exchanging”  scope but keeping the overall cost the same. This results in delivering early business value aligned to the business priorities.
Wins for the Supplier
– The initial T&M phase helps the supplier to evaluate the unknowns and extrapolate to provide a more realistic timeline and cost, and most of all provide realistic commitments on deliverables.- Sizing allows the supplier to manage their resources, as well as keep the client happy by reducing uncomfortable confrontations on change requests that we are so typically used to seeing.
– Agile project start showing business value at a very early stage
§Agile project welcome the change and accommodate it in lieu of lower prioritized features
– Agile teams plan in terms of capacity and velocity and this may not be constant
– Agile teams provide deliverables of working software incrementally and iteratively
– Agile project plan, design and build solutions that are “just enough”
– Agile project do not have upfront detailed designing and requirement analysis time to produce estimates for the entire project
– Agile project invest more in prevention of issues by using TDD, Automated testing etc. rather than in fixing of issues
– Agile project expect availability of customer during the entire lifecycle of the project

Agile fixed price contracts – Terms and terminologies


It is essential that the two contracting parties have a common understanding on the terminologies used in the contract and during the execution of the project. The main terminologies used in Agile projects that influence the language of the contract are:
Iterations/ sprints: Determines the time-boxed periods of fixed duration, normally two to three weeks
– Velocity: Determines number of iteration required to complete a project
– Acceptance criteria: Determines if a requirement is completed
– Definition of “done”: Determines if the client accepts the requirement as complete
– Business value: Determines the impact of a requirement to its business
– Sizing: Determines the size of the scope to cover in a story, iteration, release or project
– “Base” architecture and design (AD): In Agile AD would evolve over time, Determine the high level design that is done upfront in order to give overall technical direction
– Release milestone: A couple of iterations completed can end in a release which is basically a release of certain features to the client
– Define payment milestone: Payment milestones can coincide with iteration milestones or release milestones
– Define the “closure”: Determine what is meant by project closure to mitigate any open ended interpretations
– Structure the language as:
“Client” agrees to
“Supplier” agrees to

We will see how all this comes together in building a good contract in the coming sections.


Whichever way contracts are written for Agile teams, there are two essential elements that need to be considered. Firstly, the contracts themselves should embody the iterative nature of Agile working:

“do a bit, show a bit, do a bit more”.

This is the theme which is emphasized repeatedly in Agile: time-boxed iterations, retrospectives, test driven development, etc. etc. It is the PDCA cycle in action.

Secondly, the contracts should motivate the customers and their representatives to maintain involvement throughout the duration of the project. Study after study has shown continued customer involvement is a key factor in ensuring the success of IT projects. Whether you are working in Agile or not, the success of the project is determined majorly by the customer involvement.

This whitepaper does not attempt at re-writing the typical building blocks of a Master Service Agreement encompassing Licensing, IP rights, Personal data protection, Confidentiality, Indemnification, Export and Import compliance etc.

The following sections will attempt to rephrase the verbiage , and re structure the terms and clauses used in a typical Statement of Work ( SOW) comprising of the following:

-The purpose
-The contract type
-Roles and responsibilities of key stakeholders
-Project governance
-Mutual obligations of customer and supplier
-Acceptance criteria for deliverables
-Deliverables with respect to Agile
-Change control
-Payment terms

Traditional Contract terms

Agile Contract terms

The purpose: why are we doing this project?

Include the purpose of Agile   delivery explicitly

•This SOW is issued in support of   development of X project
•This SOW is issued in support of   development of X project
•The   project goal is to achieve early business value in an incremental and   iterative way

Contract  type, model & standards

What kind of contract agreement between both parties?

agile contract types

Mention the contract type chosen explicitly and the rationale for the same

•Fixed price
•Fixed price + incentive
•Time and material
•Agile fixed price
•Agile hybrid (time & material with   cap + fixed price)
•Agile time & material

Project   execution model and standards: how the project will be executed? Explicit emphasis on Agile as the chosen project execution   methodology and the quality standards

•Project management processes like PMI,   prince2
•Quality standards like ISO
•Any other standards like six sigma
Agile methodology for execution
Software sizing process for project   scoping and change management with defined sizing framework
Product quality standards specific to   the industry

Traditional contract terms

Agile contract terms

Scope, schedule & cost

agile contracts

Project   scope: how much are we going to deliver?

In Agile, you can measure the amount of scope to deliver and the   scope changes as ‘points’

•As per the software requirements   specification (SRS) document
•X number of size units (story points,   epic points, XYZ points)
•Explain the sizing method and framework

Project   cost: how much will it cost?In Agile, you are buying/ selling measurable business value as   ‘points’

•The fixed price of $X for the original   scope
•Changes cost extra $X as per the   additional effort/ hour

E.G.:   1000 person day project; costs $100,000

Note:   paying for the effort

•$X per size unit delivered
•Changes cost $X per additional size   unit

E.G.:   500 story points; costs $100,000

Note:   paying for the delivered ‘business value’

Project   schedule; when are the deliverables expected?

The milestones are based on product deliverables and not just the process hand-offs

•Architecture document by <date>
•High level design by <date>
•Status reports by <dates>
•UAT by <date>
•Final release by <date>
•Architecture choices by <date>
•Iteration frequency <weeks>
•Iteration0 start <date>
•Size (points) planned per iteration
•Size (points) planned per release
•Demo <dates>
•Release milestones <dates>
•UAT <dates>
•Final release <date>




Project   managers: who are the primary responsible parties on both sides?The primary responsibility of the project managers remain the same

•X is the supplier project manager   responsible for day to day management, conduct and performance of supplier   employees and deliveries
•Y is the client project manager and   interface to the supplier; responsible for the project and accuracy of the   SOW
•X is the supplier project manager   responsible for day to day management, conduct and performance of supplier   employees and deliveries
•Y is the client project manager and   interface to the supplier; responsible for the project and accuracy of the requirement

Additional   roles: who is responsible for scope and validation?The product owner role is most important and mandatory

•There will be a designated ‘client   product owner’ who will liaise with the supplier team to ensure that the   requirements are prioritized and verified at defined frequency of   <frequency>

Project governance

Project   meetings:   the strategic and operational meetingsThe meetings are oriented towards product demo and prioritization   rather than mere status

•Kick-off meeting
•Steering committee meeting every X   weeks
•Weekly operation review meetings
•Closure meeting
•Kick-off meeting
•Steering committee meeting every X   weeks
•Weekly operation review meetings
•Release planning meeting (with the   product owner)
•Iteration demo & feedback every X   weeks (with the product owner)
•Closure meeting


Traditional Agile
è Project   status reporting: how do you measure the progress and forecast completion?The reporting is based on pre-agreed quantitative measures on product   completion & product quality
•Supplier is required to provide a   status report every month using metrics (time spent, effort spent, schedule   variance, effort variance), qualitative analysis and forecast using a method   like earned value
•Supplier is required to provide   quantitative statistics during the steering committee:
•Size planned till date
•Size delivered till date
•% Scope change (size points)
•% Product completion
•% Release completion
•Release dates
•Variances to the above
•Technical metrics (code coverage, test   coverage etc.)

Mutual   obligations

Description of services: what are the obligations from the customer?

Customer involvement and acceptance during the product build has to   be explicit in the contract

•Customer will provide the
•Software requirements   specification (SRS) document
•Acceptance terms
•Customer will provide the
•SRS document (if working with upfront   requirements)
•Product vision (at the beginning of the   project)
•Every release:
•Requirements priority
•Requirements acceptance criteria
•Requirements feedback & changes
•Review the sizing and re-sizing (scope   changes) as needed



Description   of services: what are the obligations from the supplier?Iterative delivery, demo, acceptance and releases are built into the   contract

•Supplier will provide the software   development services
•Acceptance will occur at the end of the   project upon:
•Delivery and approval of software, UAT,   installation, commencement and completion of trial run, integration of the   modules with core system
•Final acceptance as per the acceptance   test plan
•Supplier will provide the software   development services in iterative cycles of X weeks (months)
•Integration will be at agreed regular   intervals of X days (hours)
•Completed requirements to be demoed   after each iteration to the PO
•Acceptance will occur for each release
•Acceptance criteria against each   requirement (agreed at the time of sizing) will be used as the acceptance   benchmark
•Final project acceptance as per the   combined acceptance criteria of each release and final test plan

Defining   acceptance: how are the acceptance criteria defined?Acceptance is pre-agreed along with the requirements sizing. Each   iteration is demonstrated. Each release gets accepted.

•At the end of the project through   UAT
•Verification of documents
•As per acceptance test plan
•Requirement level:

Definition   of ‘done’ (acceptance criteria, i.e., the tests are successfully passed)

•Iteration level:

X%   of the features are successfully demonstrated

•Release level:

Quality   (bugs) within agreed range


Final   sign-off

The next elements that need to be looked upon are :


What are the deliverables expected from the supplier ?

Change Control:

How to manage the changes?Changes are allowed for free if there is no extra size to be   delivered

Payment terms, warranties, cancellation, payment schedule:

When the supplier gets paid? What are the payment terms in agile contracts? How do you define the warranties? How are the payments linked to deliverables?

The blog is quite a bit long and if you need more details on deliverables, payment terms, etc and a simulation of the payment schedule in agile:

just ask me (put your request here) and I will be happy to share more material on agile contracts.

Alternatively, you can download the Agile contracts whitepaper here

You can watch the first part of the Agile contracts webinar on youtube

Will be happy to discuss on this topic, feel free to connect with me on LinkedIn

Long live Agile ! 😉



Never miss a story!

Sign up for our newsletter and get the best stories delivered to your inbox.

Co-founder of People10, a 'total agile' software development and consulting company

1 Comment

  1. RJReplyJune 16, 2014 at 10:02 am 

    Hi Nisha,

    I’d be interested to try the (beta?) sizing framework you’ve come up with. I have my own thoughts on how to create one for myself based on my experiences with agile teams. However, would like to get some pointers since you seem to have been doing this for a while now.

    Btw: quite liked your post on “SP Estimation: simplified”. Just what one needs to kickstart their estimation process. There is so much ambiguity regarding agile estimations, it’s crazy. Specially given the fact that Agile is almost mainstream now.

Leave a Reply

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

4  +  1  =