How to Use Agile on Fixed Price Contracts

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’s very principals — willingness to react to and embrace change — 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.

Clients who ask for development work often have a set budget. And, if they don’t have a technical background, they see no reason to be flexible. So they’ll demand fixed-price contracts, even on Agile projects.

Often, they simply need more education. It’s 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’ll be willing to follow your leadership and embrace a new model.

But what happens when they don’t? 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).

Here’s how to do it:

Determine Scope

When a client suggests using a fixed price payment model, what they’re saying is that they have a determined budget and are unwilling to spend more than that. If you accept this, all that’s left to do is determine the scope of the project — in other words, what do they get for their money?

The key to determining the scope of the project is limiting “scope creep” while also nailing down the requirements for the project. You’ll 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’ll see in a minute. Deploy Agile principals here — be ready to embrace change.

The key here is to nail down the major “pillars” 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’ll 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 “definition of done.”

What is a “definition of done?” Simply, it’s 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 “definition of done” — the point at which every agreed-upon requirement is complete.

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 “done.” Once every requirement is “done,” then this will meet the “definition of done” for the project overall.

But remember, this is just the starting point. Requirements and scope will change as the project develops. Let’s move on to step two:

Narrow the Requirements

With a clear understanding of the “definition of done” it’s 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 — while avoiding scope creep or feature creep. When we do this at Capital Numbers, we discuss:

• The required documentation
• The testing environment
• Meeting and participation requirements
• Client involvement — including feedback on finished stories

Keeping the definition of done in mind, we go over all the requirements to determine an estimation.

Most firms will assign a Fibonacci point system to each story. Short requirements that will be easy to complete will get maybe 1 -5 points, whereas larger stories may be put on the scale at 40 or 100 points. The determining factor here is where each requirement falls on a scale of known to unknown. Easy requirements will be a matter of routine, but it’s impossible to know the details of implementation in 40 or 100 point stories, so the client should be made aware of this fact.

Let’s take a moment here to talk about velocity in regards to the project. Velocity is the speed at which the project progresses. You must plan for this in advance. The expected time to complete the project may technically put you over budget and behind schedule, and you’ll have to make changes to the requirements.

Change for Free?

When determining velocity – AKA how many points the team will complete per iteration — you will notice that when you’re forced into fixed-price constraints, in addition to the normal time and labor constraints, you’ll have to perform some tradeoffs.

Something else you can do at this stage is to implement a “flexibility matrix” and determine what tradeoffs will be appropriate given the constraints. If you can’t do a project with ALL the requirements, ON the scheduled time, AT the fixed price, you might have to change them around or jettison them completely.

Clients usually demand fixed price projects when they’re concerned with protecting themselves against cost increase and schedule creep. However, this kind of contract can also work against them. What they’re giving up is innovation and flexibility and creativity — which Agile teams are very good at.

Here’s the point: if your client really wants to get the most benefit out of an Agile team, they’ll be interested in a fixed-scope project instead. This option allows features to be added — but every time a feature is added, another is taken away.

This sort of option can actually be very beneficial for the client because they’ll still be paying the same amount, but as the project takes shape, they can ask that certain requirements be abandoned and others be added. This way, they’ll end up with a working product that is more of a fit for their vision, while accommodating their price point.

Conclusion

It’s possible, but not ideal, to work on a fixed-price project with an Agile framework and Agile teams. If you take this kind of project, you’ll have to do a lot of upfront work. And in fact, this is the area where Agile principles will work in your favor. You’ll get many of the benefits of an Agile framework at the beginning of the project, as you estimate the requirements, determine stories, and go back and forth with the client to determine how the project will actually look.

You also might suggest a “Change-for-Free” model, where the requirements change as the project progresses, but the price does not. Under this model, you can add certain requirements as long as you remove previous requirements.