As mentioned in a previous post (http://www.jankremer.net/category/all-things-agile/) it’s human nature to plan as much ahead as possible. This behavior is seen during project contract negotiations as well. Procurement usually wants to know what value they will get for their money. Value as in ‘which requirements will the project deliver’. More interesting, they usually want a delivery date as well, making the project fixed in time, scope and budget. How does this work with an agile delivery approach, where we promote ‘adaptation’.

Let’s first look at two common contract types:
1) Variable-price, fixed-scope (Time & Material) – Here the price is flexible, usually within a tolerance or a maximum, and during the project Change Orders manage any additional requirements or functionality. If the project is not scoped properly or the world is changing during the project life cycle, you will have a lot of change orders.
2) Fixed-price, fixed-scope (Fixed Price) – Here only time is flexible, although customers usually have a deadline or Go Live expectation as well. This works really well when you know exactly what you want and the supplier is willing to agree to a price upfront. Because there is a risk involved, suppliers will add a risk premium to the price for any unforeseen things. It also means Change Orders for any additional or changed requirements.

One of the key principles for an agile delivery approach is ‘Adaptation’. Agile projects inspect and improve throughout the project life cycle. Prior to an iteration (Sprint) requirements (User Stories) can be added to the product backlog. As long they are not part of a Sprint, they can be updated or deleted. And this will happen throughout the project.

Variable-price, fixed-scope (Time & Material)
A Time & Material contract will work for an Agile project depending on how you define ‘price’ and ‘scope’. The price could be defined as an estimated number of resource days. An agile project is basically Sprint output driven and you could define scope as a number of Sprints outputs, a ‘potentially releasable product increment’ as shown the in the example below.

Example  
Deliverable 1 5 Product Increments
Description Following the incremental software development approach, <supplier> will provide development capacity to deliver 5 software increments based on the items recorded in the agreed Product Backlog.

A software increment will be reviewed by <customer> at the end of each sprint at which point <customer> will provide initial feedback.

Changes or defects will be recorded in the Product Backlog, prioritised and put forward for planning in the next Sprint.

Responsibility <supplier>
Acceptance Criteria Acceptance criteria are defined for each item in the Product Backlog. The software increment shall be accepted for items meeting the acceptance criteria, items not meeting the acceptance criteria will be recorded in the Product Backlog, prioritised and put forward for development in the sprints ahead.
Acceptance Process <Customer> to perform acceptance testing for the product increment the week after Sprint completion, and produce a test report within the same week.

Fixed-price, fixed-scope (Fixed Price)
The second contract type, Fixed Price, is the most difficult to draft for Agile projects. If you fix ‘price’ and ‘scope’ the only variable is your product quality. While development teams use User Stories with acceptance criteria and the way of working is based on inspection and adaptation, a fixed scope will simply not work and will cause frustration and disputes.

Fixed Price contracts usually fix costs based on resource days. They should not contain a list of requirements as these may change. In order to give some direction of what the project is aiming to deliver, and to get the contract signed off by procurement, you could list high level ‘candidate’ Use Cases. However, this is dangerous as it sets customer (and legal) expectations which might not be met. The more detailed scope description, the more quality will be compromised. Remember: the supplier will ‘earn’ money with less effort, while the customer will earn value by postponing acceptance and squeezing in new requirements. There is always room for interpretation, and detailed requirements will not improve trust or collaboration.

Fixed-price, variable scope (Budget box)
The best way to contract an agile project is through a third option:
3) Fixed-price, variable scope (Budget box) – Here the price, based on resource capacity, is fixed and the product owner has the flexibility to influence requirements and its quality. The budget is ‘boxed’ and provides flexibility for the customer. If the product owner wants the development team to paint the walls purple, then that’s what the team will do…

Customers (Product Owners) must now deal with variable scope. They can prioritise product backlog items by business value. From a finance point of view this is also a interesting way to contract as there will never be an overrun. And as each Sprint delivers a releaseable product, the project will always deliver.

However, there is one catch. This way of ‘contracting’ requires a healthy level of trust between supplier and customer. How do you know your supplier will provide you with the best resources and a team that will be delivering the best quality?

Summary
An Agile contract should support the Agile principles transparency, inspection and adaptation. Agile projects usually have fixed development capacity (team) and are time boxed by a number of iterations. Therefore Fixed Price, based on resources and time, and a variable scope, managed through a product backlog, are sound starting points.

It is not a good idea to fix scope in any way. Suggesting candidate product backlog items may be a way to get around procurement, but it sets expectations which may not be met. The team will deliver as per contract, probably by compromising on quality, and it will not deliver best business value.