Agile With Fixed Pricing?


I am starting a company and am considering agile development, but I don't understand how a Fixed Price contract (the type I would like to use), could work. It seems like the point of Agile is to keep things versatile and always bubble important issues/requirements to the top. Can this work in the Fixed Price world? Are most Agile contracts just a deep bucket of money that can be dipped into until it runs out? How do you handle change management?


Pricing Contract Agile

asked Mar 14 '11 at 10:36
254 points

6 Answers


Those things are completely unrelated.

You seem to be entertaining either doing consulting/developing for others or hiring others to develop for you (it's unclear from the question).

Agile is how you go about the development process. In case of hiring others, development process is not handled by you, so the question would make little sense, so I'll assume you're talking about providing development services for others.

In that case the requirements are fixed and given by people who hire you. Fixed price vs. compensation per hour only determines how are you going to be paid for completing the contracted work. Which payment method you choose should depend on what you believe will make you more money. Fixed price is more risky (if you underestimate the number of hours needed, your per hour compensation will go down) but if you think you can complete a project quickly and ask a high fixed price for it, you might go for it.

Agile is a development process i.e. ideas and practices for structuring your development work to achieve your end goal faster.

Some of the principles of Agile do not apply to the world of short-term contract programming. In contract programming the requirements are specified upfront. You are being paid for implementing exactly what is specified, quickly.

Parts of the Agile process involves management of requirements. In contract work requirements are usually given to you and you have no authority to change them so those parts of the Agile process are not applicable. Non-applicable, however, is not the same thing as contradictory.

Agile consists of very rich set of practices. It's not meant to be applied verbatim and 100%. It's up to you to choose the practices that make sense in your particular situation, given your particular constraints.

answered Mar 15 '11 at 13:25
Krzysztof Kowalczyk
1,950 points


we provide this option for our clients now.

For clients asking for fixed price development we have our Blueprint Process which makes the client sign off the "goal" before we start. Changes to the goal are then handled as change requests to the original quote. This is exactly the same as an agile process but with a signature showing understanding at each step along the way.

We still break the development it into sprints and provide a "deliverable" per sprint. They can still change their mind for subsequent sprints but they sign off a change request ... all it really does is help manage their expectations and create a higher workload for the project lead as they have to actually think ahead and plan out sprint deliverables properly.

answered Mar 15 '11 at 15:36
Robin Vessey
8,394 points
  • Great answer +1. Agile is how software is built, Fixed pricing is based on the SCOPE of the project. Managing your project through an Agile method should not change the actual product. My 2cents on fixed pricing, Its best to use it only on VERY SMALL projects which take 3 months or less, and 3 people or less. Larger projects are always cheaper with an Hourly rate with bonus structure based on milestones. BASED ON MY TRIAL AND FAIL EXPERIENCE – Frank 13 years ago
  • Thanks. Yeah we try to get the client to commit to – Robin Vessey 13 years ago


Very simple.Fixed price = fixed effort (i.e. X sprints). Features get prioritized. Anything that does not fit in the budget is cut. Voila - fixed price.

answered Mar 14 '11 at 15:00
Net Tecture
11 points
  • Wouldn't that really be defining all sprints up front though when planning the schedule? I thought agile was more in favor of reassessment and reprioritization at each iteration of outstanding tasks. – Skaz 13 years ago
  • Yes and no. if you run out of money, you run out of money. – Net Tecture 13 years ago


From the Agile Manifesto, the latter two priority points present specific challenges for fixed price contracts:

"[We value] Customer collaboration over contract negotiation" This is either pretty straightforward, or else impossible, to reconcile. The principle is that the contract does the job of defining commercial terms.

A 'classic' development contract that sets out waterfall-style milestones etc is obviously anti-agile. If the customer requires this non-collaborative approach, some agile ideas may help you in your internal processes, but don't kid yourself.

However, the collaborative approach will often include helping the relevant manager to create a contract that will satisfy internal procurement processes based on price-for-scope, but create what should be more valuable to the manager, price-for-progress.

You can fix the total contract price, or the price per month, or pretty much anything you like, and be fully agile.

"[We value] Responding to change over following a plan" Agile doesn't say, "don't plan." It just says it's crazy to follow the plan blindly when the world changed. Again, traditional buying processes tend to look exactly the opposite of us. But this is an easier reconciliation.

In some cases, especially smaller projects or ones driven by external factors such as compliance, there is no significant likelihood of change. In others, this is a minor contractual issue (what is the mechanism within the contract to allow for variation), but more importantly a relational one (how do we stay engaged with stakeholders so that situational change is discovered quickly and embraced organically.

If you are truly embracing agile, and change arrives such that the project doesn't make sense, or can be reduced, or considered complete early - be ready to give the customer the gift of freedom to end up below the fixed price.

answered Mar 18 '11 at 18:11
Jeremy Parsons
5,197 points


I read a lot of great stuff on VersionOne's website. They have a free trial too (or it might even be free for 1 project or something).

They have a tutorial section, and in about an hour you can have a pretty good working knowledge of the Agile process. I just read it a few days ago.

answered Mar 15 '11 at 23:26
1,171 points
  • Thanks, I'll take a look. – Skaz 13 years ago


Agile does not imply you don't have a target of what to build nor a solid definition of what is in scope and out of scope.

The beauty of Agile is that the sprints are short and compact. That allows you to define places where incremental change can be captured.

My advice would be to get the best up front scope you can, have a solid change order process and make the sprints short so that you can limit any downside for scope creep.

answered Mar 14 '11 at 10:57
Jarie Bolander
11,421 points
  • I thought a decent focus of Agile was that there isn't huge up-front requirements gathering as requirements tend to naturally change. Am I thinking about it the wrong way? Any tips/links on change order process? I haven't been through that before. Thank you for your help. – Skaz 13 years ago
  • It has that flexibility but if you are doing a fixed bid contract, you need to know what's in scope and what's out of scope. Usually, Agile can be broken into phases. Each phase has a clear set of deliverables. Anything outside those deliverables is out of scope for that phase. – Jarie Bolander 13 years ago

Your Answer

  • Bold
  • Italic
  • • Bullets
  • 1. Numbers
  • Quote
Not the answer you're looking for? Ask your own question or browse other questions in these topics:

Pricing Contract Agile