{"id":4779,"date":"2019-04-26T04:35:01","date_gmt":"2019-04-26T04:35:01","guid":{"rendered":"https:\/\/www.capitalnumbers.com\/blog\/?p=4779"},"modified":"2025-08-11T07:45:31","modified_gmt":"2025-08-11T07:45:31","slug":"how-to-use-agile-on-fixed-price-contracts","status":"publish","type":"post","link":"https:\/\/www.capitalnumbers.com\/blog\/how-to-use-agile-on-fixed-price-contracts\/","title":{"rendered":"How to Use Agile on Fixed Price Contracts"},"content":{"rendered":"

When the ideas behind Agile teams and frameworks were first developed, nobody expected to use them under fixed-price contracts. In fact, the idea seemed ridiculous at first. Agile\u2019s very principals \u2014 willingness to react to and embrace change \u2014 seemed logically inconsistent with the demands of fixed price contracts. However, it quickly became apparent that although Agile teams and frameworks comprise an innovative way to predict, react to, and take advantage of the shifting demands of project development, clients are unwilling to embrace the complementary pricing structures.<\/p>\n

Clients who ask for development work often have a set budget. And, if they don\u2019t have a technical background, they see no reason to be flexible. So they\u2019ll demand fixed-price contracts, even on Agile projects.<\/p>\n

Often, they simply need more education. It\u2019s your job to manage their expectations and make them understand that Agile teams are limited under a fixed contract. You can point to several better payment models, such as a build and develop model, hourly rates, etc etc. Sometimes they\u2019ll be willing to follow your leadership and embrace a new model.<\/p>\n

But what happens when they don\u2019t? If a client demands a fixed price while using Agile teams, you basically have two options. The first is that you can refuse. The second is to work out a compromise by which you can run under Agile teams under a fixed price contract (or similar).<\/p>\n

Here\u2019s how to do it:<\/p>\n

Determine Scope<\/h2>\n

When a client suggests using a fixed price payment model<\/a>, what they\u2019re saying is that they have a determined budget and are unwilling to spend more than that. If you accept this, all that\u2019s left to do is determine the scope of the project \u2014 in other words, what do they get for their money?<\/p>\n

The key to determining the scope of the project is limiting \u201cscope creep\u201d while also nailing down the requirements for the project. You\u2019ll have to draw up a document containing all the requirements. NOTE: having a very detailed, point-by-point requirements document will actually work against you, as we\u2019ll see in a minute. Deploy Agile principals here \u2014 be ready to embrace change.<\/p>\n

The key here is to nail down the major \u201cpillars\u201d of the project so that you and the client both have a goal to work toward. You can implement user stories and story points as a way to specify the requirements of the projects and estimate the costs of each (we\u2019ll get to that in a minute). However, the number one factor that will guarantee your success with using Agile teams under a fixed price project is having a \u201cdefinition of done.\u201d<\/p>\n

What is a \u201cdefinition of done?\u201d Simply, it\u2019s the best way to prevent surprise requirements, scope creep, and mistrust between client and contractor. The client and the developer must both agree on a \u201cdefinition of done\u201d \u2014 the point at which every agreed-upon requirement is complete.<\/p>\n

Have a sit-down or a consultation with the client and go down the list of requirements, one by one. Explicitly discuss each and determine what needs to be complete in order for each requirement is \u201cdone.\u201d Once every requirement is \u201cdone,\u201d then this will meet the \u201cdefinition of done\u201d for the project overall.<\/p>\n

But remember, this is just the starting point. Requirements and scope will change as the project develops. Let\u2019s move on to step two:<\/p>\n

Narrow the Requirements<\/h2>\n

With a clear understanding of the \u201cdefinition of done\u201d it\u2019s time to take the requirements to your team and get an estimation of cost. Time-box this session and flesh out the necessary user stories \u2014 while avoiding scope creep or feature creep. When we do this at Capital Numbers<\/a>, we discuss:<\/p>\n